A system design interview template

Treat these time boxes as a starting point, not a schedule you must defend. Confirm the interview length and adjust when the interviewer asks for a deeper discussion.

Keep a small requirements list beside the diagram. Every major component should support a requirement, enforce a correctness rule, or address a specific bottleneck.

Start with user actions rather than infrastructure. For a URL shortener, ask whether users need custom aliases, expiration, analytics, or editable destinations. Agree on the core flow before adding optional features.

Separate functional requirements from quality targets and correctness rules. Low redirect latency is a quality target; never assigning the same active code to two destinations is a correctness rule. If the interviewer leaves something open, state an assumption and invite correction.

Use back-of-the-envelope estimates to identify pressure points, not to fill the board with arithmetic. Distinguish average traffic from peak traffic, and request rate from concurrent connections. State whether each input came from the prompt or is your assumption.

For example, assume 10 million daily active users each make 20 reads per day. That is 200 million reads per day, or roughly 2,300 reads per second on average. If you assume a peak of five times the average, plan the discussion around roughly 12,000 peak reads per second, then explain which layer must absorb that load.

Sketch only the APIs needed to explain the main flows. Include inputs, identifiers, important responses, and retry behavior. For booking, a request that creates a temporary hold is different from one that confirms a reservation, so expose that distinction.

Then describe the source-of-truth records and their access patterns. Choose a database based on required transactions, queries, indexes, and scale rather than saying that SQL cannot scale or NoSQL is always faster. Make the atomic boundary explicit: what must commit together, and what can happen later?

Start with a design that can serve the agreed workload: clients, request routing, application logic, and durable storage. Add a cache, queue, object store, or specialized index only when you can explain what it solves. A small number of well-defined services is easier to reason about than a diagram full of unexplained microservices.

Walk through one write and one read from start to finish. Say when the system acknowledges success, where data becomes durable, and which steps are synchronous. If background processing is involved, show how work is recorded durably and how its status becomes visible.

Propose one or two areas and ask which the interviewer wants to explore. The best deep dive is usually where scale, concurrency, or failure threatens a core requirement. Do not spend ten minutes on load balancing when the problem is preventing two buyers from purchasing the same seat.

For each decision, state the requirement, a viable alternative, your choice, and its cost. For example: “I will use conditional updates for seat holds so competing requests cannot both acquire the same seat. Contended requests may fail and retry, so I will also limit admission during bursts.”

Challenge the design with concrete failures: a worker crashes after performing a side effect, a database write succeeds but the response is lost, or a cache serves an old value. Explain what the client observes and how the system recovers. A retry is not a complete answer unless you explain whether repeating the operation is safe.

State consistency requirements per operation. Search results may tolerate delay while inventory allocation requires an atomic decision. Check authorization on protected resources, including paths through caches and background workers; possession of an object ID should not imply access.

Identify the first likely bottleneck before proposing sharding or more regions. Name the constrained resource: CPU, database write throughput, storage, network transfer, connection count, or a hot partition. Explain what measurement would justify the next architectural change.

Tie monitoring to user-visible behavior and internal health. Useful signals include request latency and errors, queue age, replication lag, cache hit rate, and rejected work. Include a correctness check where needed, such as reconciling payment records against external settlement results.

Use the final minutes to summarize how the design meets the agreed requirements. Name the two most important trade-offs and one unresolved risk. For example: “Redirects use a cache to reduce database reads, but destination edits may remain stale until invalidation or expiration. The next scaling concern is a small number of extremely popular codes.”

Adapt the framework to the prompt. A distributed cache interview needs early discussion of ownership, eviction, and failover; a payment interview needs early discussion of ledger correctness and uncertain outcomes. If time is short, prioritize a complete core flow and its hardest correctness problem over optional features.