Skip to main content

How to Answer a System Design Interview Question

Every lesson before this one built vocabulary — scalability, consistency, caching, sharding, the tradeoffs between them. This lesson is different: it's the framework for actually using that vocabulary under interview conditions, in the right order, without freezing up in front of a blank whiteboard. Every problem in the rest of this module follows the exact structure below, so understanding it once here pays off across all of them.

The six-step framework​

System Design Lab

1. Clarify requirements before designing anything​

The single most common mistake in a system design interview is starting to draw boxes before knowing what the system actually needs to do. Separate functional requirements (what the system must do — "users can shorten a URL," "a message must be delivered to the recipient") from non-functional requirements (the qualities the system must have — availability, latency, consistency), and explicitly ask which ones matter most for this specific prompt. A URL shortener and a payments system are both "just" a service with a database, but their non-functional priorities — availability and low latency for one, strict correctness for the other — point toward completely different designs. Getting this wrong at the start means the rest of the interview is spent designing for the wrong problem.

2. Estimate scale​

A rough, order-of-magnitude estimate of traffic and data volume — reads per second, writes per second, total storage over a year — determines almost every design decision that follows. The exact numbers matter far less than demonstrating the habit: a system handling 100 requests a second doesn't need sharding; a system handling 100,000 a second almost certainly does. This estimate is what justifies every scaling decision made later in the interview instead of reaching for horizontal scaling or a cache reflexively, without a stated reason.

3. Design the API​

Before designing internals, define the contract the system exposes — the same API design habit of naming the method, path, and response explicitly rather than describing an interaction in prose. This step also naturally surfaces requirements that were missed in step 1: trying to write POST /urls forces you to decide whether a custom alias is supported, whether an expiry date is required, and other details easy to skip past in a purely verbal requirements discussion.

4. Model the data​

Sketch the core entities and their relationships — what tables or documents exist, what the primary key and important indexes are. This is where a SQL vs. NoSQL decision gets made concretely, informed by the access patterns the API design just revealed: if the dominant operation is "look up one row by a single key," that points toward a very different data model than "query flexibly across several fields."

5. Sketch the high-level design​

Draw the major components and how a request flows through them — client, load balancer, application servers, database, cache — before drilling into any single piece. This is the moment to place the pieces from earlier modules where they actually belong: a Load Balancer in front of stateless application servers, a cache in front of the database for the read-heavy paths the scale estimate identified, an API Gateway if there's more than one backend service involved.

6. Deep-dive and discuss tradeoffs​

Only after the full picture exists should the conversation go deep on one or two of the hardest parts — how short codes are generated without collisions, how a rate limiter's counters stay consistent across instances, whatever the specific problem's interesting question actually is. This is deliberately the last step, not the first: going deep on one component before the overall shape exists risks running out of time having only solved one-tenth of the problem impressively.

What actually gets evaluated​

An interviewer is rarely grading against one specific "correct" architecture — they're evaluating whether you can navigate tradeoffs out loud: naming the CAP Theorem choice a design makes and defending it against the specific requirements gathered in step 1, rather than reciting facts with no connection to the problem at hand. Following the six steps in order is what creates the natural opportunities to do this — each step's decisions are justified by what came before it, which is exactly what makes the answer sound like reasoning instead of a memorized template.

Why this matters, restated once more​

Every problem lesson that follows this one is organized around exactly these six steps, in this order, specifically so the structure becomes automatic rather than something to reinvent under pressure in a real interview. The value of practicing several problems isn't memorizing their specific answers — real interview prompts will differ — it's internalizing this order until reaching for it doesn't take conscious effort, leaving full attention for the actual design decisions.

Following a structured framework vs. improvising: pros and cons​

Pros

  • Guarantees requirements are clarified before any design commitment is made
  • Creates natural, justified checkpoints for discussing tradeoffs as they come up
  • Prevents spending the whole interview on one component while the big picture is unaddressed

Cons

  • Can feel rigid or slow for a prompt that's genuinely simple and doesn't need every step
  • Requires practice to execute smoothly rather than reading as a rehearsed checklist
  • Still requires real judgment about how much time each step deserves for a given prompt

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.