System Design Interview Guide

What interviewers actually evaluate

A system design interview is not a quiz with one correct diagram. The interviewer is watching how you handle an ambiguous problem: whether you ask questions before building, whether your numbers drive your choices, and whether you can explain what each decision costs.

Most rubrics reduce to five signals. Strong candidates show all five, even when their final architecture is ordinary.

• Problem framing: you turn a vague prompt into explicit requirements, non-goals, and success criteria.
• Scale reasoning: you estimate traffic, storage, and latency, and let those numbers justify your choices.
• Architecture: you produce a coherent end-to-end design with clear component boundaries.
• Trade-offs: you name the alternatives you rejected and why.
• Resilience: you describe what breaks, how you would notice, and how the system recovers.

A 45-minute time budget

Candidates most often fail by spending the whole hour on one component. A rough budget keeps the conversation balanced. Treat these numbers as a starting point and adjust if the interviewer steers you elsewhere.

Step 1: clarify before you draw

The first minutes decide the rest of the interview. Ask questions that change the design, not questions that sound thorough. A useful test is whether a different answer would produce a different architecture.

• Who are the users, and what are the two or three core use cases?
• What is explicitly out of scope? Naming non-goals protects your time.
• What is the expected scale: users, requests per day, data size, growth?
• Is the workload read-heavy or write-heavy, and what is the read-to-write ratio?
• What latency matters, and for which operations?
• Is strong consistency required, or is eventual consistency acceptable?
• What availability target is expected, and what is the cost of downtime?

Write the answers on the board. They become the contract you check your design against at the end.

Step 2: estimate the numbers you need

Back-of-the-envelope estimation is about orders of magnitude, not precision. The goal is to learn whether you are designing for tens, thousands, or hundreds of thousands of requests per second, because that changes whether you need a cache, sharding, or a queue.

A day has about 86,400 seconds, so it is convenient to round to roughly 100,000. Divide daily volume by that to get average requests per second, then multiply by a peak factor, commonly between 2 and 10 depending on how bursty the traffic is.

Storage works the same way: records per day, times bytes per record, times retention. A service that stores 1 KB per record and receives 100 million records a day writes about 100 GB per day, or roughly 36 TB per year before replication.

It also helps to remember rough latency orders of magnitude. These are approximations that vary by hardware, but the ratios are what matter: a memory access is around 100 nanoseconds, a random read from an SSD is roughly 100 microseconds, a round trip inside one data center is around half a millisecond, a spinning disk seek is on the order of 10 milliseconds, and a cross-continent network round trip is around 150 milliseconds. The lesson is that a network hop costs far more than a memory access, and a cross-region call costs far more than a local one.

Step 3: draw the critical path first

Start with the simplest flow that satisfies the main use case: a client, a load balancer, a stateless service, and a data store. Only after that works end to end should you add components, and each addition should be motivated by a number or a requirement you already stated.

Common building blocks and the problem each one solves:

• Cache: reduces read latency and database load for data that is read far more often than it changes.
• Message queue: decouples producers from consumers, absorbs bursts, and lets slow work happen asynchronously.
• CDN: serves static or cacheable content close to users and offloads origin traffic.
• Read replicas: scale read throughput, at the cost of replication lag.
• Sharding or partitioning: scales writes and storage beyond one machine, at the cost of cross-shard queries and rebalancing.
• Search index: supports text and multi-field queries that a primary database handles poorly.

Step 4: state the trade-off out loud

Every component choice trades one property for another. Interviewers listen for the sentence "I chose X over Y because...". If you cannot say what you gave up, you probably have not made a decision yet.

Step 5: test failure and scale

Finish by walking your own design through the ways it can fail. This is where average answers become strong ones, because it shows you think about the system after launch, not just on the whiteboard.

Questions worth asking about your own diagram:

• What is the single point of failure, and how would you remove it?
• What happens when a dependency is slow rather than down? Timeouts, retries with exponential backoff, and circuit breakers prevent a slow service from taking everything else with it.
• Are retried operations idempotent? A retried payment or message must not be applied twice.
• Where can one hot key or hot partition overload a single node?
• How stale can a read replica or cache get, and is that acceptable?
• How will you know something is wrong: which metrics, logs, and alerts exist?

A worked estimate: a URL shortener

Suppose the prompt is a URL shortener and you agree on 100 million new links per month with ten reads for every write.

Writes: 100 million per month is about 3.3 million per day, or roughly 40 writes per second on average. Reads: ten times that, about 400 per second on average, perhaps 1,200 at peak. This is a modest load, which tells you a single well-indexed database with a cache in front can carry it, and you do not need to shard on day one.

Storage: if you keep each link for five years, that is about 6 billion records. At roughly 500 bytes each, that is about 3 TB before replication, which fits on one modern database server but is large enough that you should plan for partitioning later.

Key length: a seven-character key using 62 characters (a to z, A to Z, 0 to 9) has about 3.5 trillion combinations, far more than the 6 billion you need, so seven characters is comfortable. Notice how each number drove a concrete decision.

Common mistakes

• Drawing components before agreeing on requirements, then discovering the design does not fit the problem.
• Skipping estimation, so every choice is a guess and no choice can be defended.
• Over-engineering: designing for global scale when the prompt describes ten thousand users.
• Listing technologies instead of explaining why: naming Kafka or Cassandra is not a decision.
• Never stating a trade-off, or presenting a choice as if it had no downside.
• Ignoring failure until the interviewer asks about it.
• Treating the interview as a monologue. The interviewer's hints are information; follow them.

How to practice

Reading solutions builds recognition, but the interview tests recall under pressure. The reliable way to improve is to solve problems yourself, review your own gaps, and repeat the weak area.

Pick one problem below, set a 45-minute timer, and follow the five steps without looking at a reference. Then review which step was weakest, such as estimation or failure handling, and choose your next problem to exercise that step.