Practice System Design Interviews with System Design Trainer

What Is System Design Trainer?

System Design Trainer is an interactive whiteboard for practicing system design interviews. You select a scenario, drag AWS or Azure components onto a canvas, connect them into an architecture, and run a deterministic capacity simulation.

The simulator estimates how much traffic each component can support, identifies the system bottleneck, and highlights architectural risks. When the design is ready, Jev can evaluate choices that cannot be judged by capacity calculations alone, including scalability, reliability, data design, and your written explanation.

Key Features

• Interactive architecture canvas: The whiteboard is built with React Flow through @xyflow/react.
• Structured practice: The project includes 15 levels across four chapters.
• Live capacity modeling: Each node displays utilization and an estimate of how many users it can support.
• Architecture diagnostics: The simulator flags single points of failure, missing load balancers, and clients connected directly to databases.
• Cost and availability estimates: The system provides additional indicators alongside throughput calculations.
• Interviewer-style evaluation: Jev scores scalability, reliability, data design, and written explanations, then recommends what to improve next.
• Custom technologies: You can enter technologies such as Kafka, MongoDB, or NGINX. Jev classifies their architectural role so the application can assign a capacity profile.
• Local progress: Designs and scenario progress are stored in the browser.
• Free play: An open whiteboard is available outside the structured levels.

Install and Run the Project

1. Install the dependencies

Clone or download the repository, open its directory in a terminal, and install the npm dependencies:

npm install

2. Create the local environment file

Copy the included environment template to .env.local:

cp .env.example .env.local

3. Configure Jev

To receive real Jev answers, add a TYPESAFE_API_KEY value to .env.local. Jev is implemented in lib/server/jev.ts using @typesafe-ai/sdk.

The application can still run without an API key. In that case, Jev responses fall back to a clearly labeled mock, allowing you to explore the rest of the workflow without external evaluation.

4. Start the development server

npm run dev

Open the local address reported by the development server to begin using the trainer.

Complete Your First System Design Exercise

1. Select a prompt. Choose a scenario such as designing infrastructure for one million users. Each scenario supplies a fixed user count and requirements.
2. Read the objectives. Levels contain required objectives and optional bonus objectives that are checked when you run the design.
3. Add cloud components. Drag appropriate AWS or Azure components onto the whiteboard.
4. Connect the architecture. Create the request and data paths between clients, networking components, application services, caches, queues, and databases as appropriate for the scenario.
5. Run the design. Review utilization, supported-user estimates, availability, cost, and architecture warnings.
6. Resolve the bottleneck. Update the design based on overloaded components or structural warnings, then run it again.
7. Request Jev feedback. Submit the design and written explanation for evaluation when you are ready.

How level scoring works

Clearing every required objective earns one star. Each bonus objective earns one additional star. Stars provide XP and contribute to your rank, while progress is retained in the browser.

Chapter 4 asks you to rebuild reference architectures from the Azure Architecture Center. After you clear one of these levels, the trainer links to the original architecture.

Understand the Capacity Model

The capacity engine lives in lib/simulate.ts. It is deterministic and does not use AI. Peak load is derived from the scenario using the following relationship:

DAU × requests per day ÷ 86,400 × peak factor

The model separates this load into reads and writes, then propagates it from the Users node through the connected graph.

How common components affect traffic

• CDNs: Absorb the portion of traffic that the scenario marks as cacheable at the edge.
• Caches: Absorb reads according to their hit rate. The model supports both cache-aside sibling placement and inline placement.
• Queues: Remove writes from the synchronous path and smooth them toward the average request rate.
• Sibling components: Components of the same kind split load evenly. For example, a load balancer connected to two application groups distributes traffic between them.
• SQL databases: Write capacity is limited by one primary.
• NoSQL databases: Write capacity scales with partitions.

Each node reports utilization and a supports ~N users estimate, calculated from the scenario user count divided by utilization. Overall system capacity is determined by the bottleneck with the lowest supported-user estimate.

Example Design Iteration

Suppose a design sends all client traffic directly to one application component and then to a database. Running the simulation may expose the application or database as the bottleneck, along with reliability warnings.

You can then revise the architecture by adding suitable distribution, caching, asynchronous processing, or data components. For example, sibling application groups behind a load balancer can split application traffic, a cache can reduce database reads according to its hit rate, and a queue can move writes away from the synchronous path. Run the model again after each change to see whether the bottleneck moved elsewhere.

A higher capacity estimate does not automatically make a design correct. Use Jev to evaluate tradeoffs in reliability, data design, scalability, and the reasoning behind your choices.

Use Jev Effectively

The deterministic simulator supplies its calculated numbers to Jev as facts. Jev then handles judgments that cannot be reduced to throughput formulas.

• Evaluation scores: Reviews scalability, reliability, data design, and the written explanation.
• Improvement choice: Selects what should be improved next.
• Checklist judgments: Produces one Noul for each scenario checklist item.
• Custom component classification: Assigns an architectural role to a technology you enter, enabling the trainer to apply a corresponding capacity profile.

For stronger feedback, make the written explanation explicit. Describe traffic flow, scaling assumptions, failure handling, read and write patterns, and why each major component is present.

Advanced Tips

Optimize the bottleneck, not every component

The system supports only as many users as its limiting component. Start with the node showing the lowest supported-user estimate. After changing the design, run the simulation again because relieving one bottleneck may reveal another.

Compare synchronous and asynchronous paths

Queues take writes off the synchronous request path and smooth them toward average load. Use the model to compare a direct write path with a queued architecture when the scenario permits asynchronous processing.

Test cache placement

The simulator recognizes caches used as siblings in a cache-aside pattern and caches placed inline. Observe how placement and hit rate affect downstream read traffic.

Watch for structural warnings

Do not focus only on utilization. Check for single points of failure, missing load balancers, and direct client-to-database connections. These warnings can reveal reliability or security-related design weaknesses even when raw capacity is sufficient.

Inspect the source behind catalog numbers

Capacity, availability, and cost data is defined in lib/catalog.ts. Each number includes a source shown in the component properties card. Values are categorized as official limits, official SLAs, vendor benchmarks, assumptions, or services with no published limit.

• Official limit: A published AWS or Azure quota, such as an account-level request throttle.
• Official SLA: A vendor's monthly uptime commitment.
• Vendor benchmark: A published performance figure that is not guaranteed.
• Assumption: A modeled value where no vendor figure is available. The project also treats all costs as assumptions.
• No published limit: A service modeled as scaling independently, so it does not become the bottleneck.

The README states that these sources were last checked in September 2026. Cloud quotas change, and many can be increased, so simulation results should be treated as estimates rather than guarantees.

Explore or extend the scenarios

Scenario definitions are stored in lib/scenarios.ts, while the 15 structured levels are defined in lib/levels.ts. Add scenarios in lib/scenarios.ts when extending the available practice prompts.

Understand browser persistence

Canvas designs are saved per scenario in localStorage, and progress is also kept in the browser. Remember that browser storage is local to the current browser profile and environment.

Conclusion

System Design Trainer combines an interactive cloud architecture canvas, deterministic capacity modeling, structured objectives, and Jev-based design review. Use the simulator to test measurable behavior, use warnings to catch structural problems, and use Jev to improve the reasoning and tradeoff analysis expected in a system design interview.