System Atlas X.
Learn system design. Build real architectures. Get senior-level review. One product with two connected modes: Learn Mode turns interview scenarios into an interview-readiness score and generated explanation, while Build Mode turns a brief into a reviewable architecture with a tradeoff engine. The win is not drawing boxes; it is helping you think, defend, and improve a design. No LLM key required.
Diagrams are the easy part.
Miro, Lucidchart, and Excalidraw already let you draw boxes and arrows. The drawing was never the hard part. The hard part is the reasoning underneath: why this database, what happens when the queue backs up, where the audit log lives, which tradeoff you accepted and why.
Two audiences need that same reasoning. Someone prepping for a system-design interview needs to practice it and defend it out loud. Someone planning a real product needs to catch what is missing before it ships. System Atlas X gives both audiences a deterministic review loop: expose gaps, explain tradeoffs, and turn the result into either an interview answer or a build plan.
Ten scenarios, graded like an interview.
Pick a scenario (URL shortener, payment processing, ride-sharing dispatch, and seven more). Each one ships its requirements, non-functionals, and common pitfalls, plus a graded set of expected, critical, and recommended components. You assemble an answer from a searchable palette and get a live Interview Readiness score with category bars, a senior-level reference architecture to compare against, and a generated first-person explanation you can rehearse.
Three choices worth defending.
The ones with real tradeoffs.
Deterministic review where trust matters.
Learn Mode’s review, scoring, and explanation logic are pure functions over a set of selected components plus a scenario. Roughly thirty rules fire on signals like a public API with no rate limiter, a queue with no dead-letter queue, or payments with no idempotency. Build Mode uses its own deterministic linter and tradeoff rules today; converging both reviewers is the next step.
A pure function is testable, explainable, and instant. The same input always produces the same review, score, and explanation, which is exactly what you want for study and for trust. Reaching for an LLM here would trade all three for a black box that sometimes invents Kafka.
A scenario is a graded spec; the reference is the answer key.
Each scenario declares which components are expected, which are critical, and which are senior signal, plus flags like hasPayments and isReadHeavy. The reviewer diffs your selection against that spec and the rule set, producing findings tagged critical, warning, suggestion, or strength, each with a one-line reason and an interview tip, and rolls them into a category and overall score.
Below, a near-complete payment design scores 84 (Strong) with two things left to tighten: a missing rate limiter on the public API and a queue with no worker. The senior reference panel is the answer key you defend your choices against.
One component model behind both modes.
A single catalog of 43 components carries a deep knowledge layer: when to use it, alternatives, tradeoffs, failure modes, interview talking points, and related components. Learn Mode reads it for a lightweight selection workspace and a browsable Component Library; Build Mode reads the same catalog for its React Flow canvas, where the architecture metadata lives inside node.data and the component kind sits in data.architectureType, kept separate from node.type.
State lives in Zustand and persists to localStorage, so there is no backend, no auth, and nothing to provision. The catalog is the one source of truth, so a new component shows up everywhere at once.
What I'd do differently.
- ·Build Mode still runs its original review linter and Markdown export, not the new shared engine. The next step is wiring it onto the same reviewer with an Architecture Confidence score and a full architecture-spec generator, so both modes are truly one engine end to end.
- ·A zustand selector that returned a fresh empty array crashed the scenario workspace under React 19, whose
useSyncExternalStoreexpects a stable snapshot. The fix was a one-line change to select the stored reference and default outside the selector, but it was a good reminder to test the empty state in a real browser, not just a passing build. - ·Local-first was the right call for shipping fast, but teams want shared links and history. The data model is backend-ready; the next step is accounts, a database, and shareable URLs without reshaping anything.