How to structure a system design interview: the requirements-first framework
A repeatable five-phase structure for system design interviews — requirements, estimation, high-level design, deep dives and wrap-up — with time budgets and the traps that sink strong engineers.
System design interviews are deliberately open-ended: "Design a URL shortener", "Design a chat app", "Design a news feed." There is no single correct answer, and that's the point — the interviewer is scoring how you navigate ambiguity, not whether you land on their favorite architecture. Strong engineers regularly fail these rounds for one reason: they start drawing boxes before they know what they're building.
The fix is a requirements-first structure. This guide lays out a five-phase framework with time budgets for a standard 45-minute round, then covers the traps that appear in almost every failed session.
The five phases at a glance
| Phase | Time (45-min round) | Goal | | --- | --- | --- | | 1. Requirements | 5–8 min | Agree on what you're building and for whom | | 2. Estimation | 3–5 min | Get the numbers that shape the design | | 3. High-level design | 10–12 min | An end-to-end architecture that works | | 4. Deep dives | 15–18 min | Depth where it matters, driven by bottlenecks | | 5. Wrap-up | 3–5 min | Trade-offs, failure modes, evolution |
The percentages matter more than the minutes: roughly a quarter of the interview happens before the first box is drawn. That feels slow. It is the single highest-leverage habit in this format.
Phase 1: Requirements — narrow before you build
Split requirements into two lists and write them down (or say them explicitly in a remote interview):
Functional requirements — what the system does. For a URL shortener: create a short link from a long URL, redirect on access, optionally support custom aliases and expiry. Crucially, also state what you're excluding: "I'll treat analytics as out of scope unless you want it" — scoping out is as valuable as scoping in.
Non-functional requirements — the qualities that shape the architecture: scale (how many users, what read/write ratio?), latency targets, availability vs. consistency preferences, durability. These aren't boilerplate; each one should later justify a design decision. If you write "highly available" and nothing in your design changes because of it, you didn't need it.
Ask the interviewer real questions here. "Is this read-heavy? Do redirects need to be strongly consistent, or is a few seconds of propagation fine?" Interviewers expect questions — a candidate who asks none is signaling they'll build the wrong thing confidently.
Phase 2: Estimation — only the numbers that change the design
Back-of-envelope estimation has one purpose: deciding what kind of system this is. You need rough traffic, storage and bandwidth figures — to one significant digit, out loud.
For example: 100M redirects/day is about 1,200 requests/second on average — call it 5,000–10,000 at peak. New links at 1M/day with ~500 bytes each is ~180 GB/year of core data: tiny. Conclusion, stated explicitly: "This is a read-heavy, small-data, high-QPS system — so the design will center on a fast read path and aggressive caching, not on storage."
That last sentence is the entire point of the phase. An estimate that doesn't produce a design conclusion is theater. If arithmetic under observation rattles you, practice the conversions until they're automatic: 1 day ≈ 86,400 seconds (round to 100K for mental math), 1M/day ≈ 12/second.
Phase 3: High-level design — end-to-end first, clever later
Draw the complete request path before optimizing any part of it: client → load balancer → application servers → data store, plus a cache and the write path for creating links. Name each component's job in one sentence as you draw it.
Two disciplines keep this phase on track:
- Boring first. A working, conventional architecture beats a novel one you can't defend. Reach for exotic components only when a requirement demands them.
- Tie choices to requirements. "Because we said reads dominate 100:1, I'm putting a cache in front of the store and I'll accept eventual consistency on new links propagating." Every arrow should trace back to phase 1 or 2.
Close the phase by walking one read and one write through the diagram end to end. This catches missing pieces before the interviewer does, and it's exactly what strong candidates are remembered for.
Phase 4: Deep dives — follow the bottleneck
Now depth. Either the interviewer picks the area, or — better — you propose one: "The riskiest part of this design is the ID generation under concurrent writes; want me to go deep there, or would you rather talk caching?"
Structure each deep dive the same way: state the problem precisely, offer two or three approaches, compare them, pick one and justify it. For URL-shortener key generation, that might mean comparing hashing the URL (deterministic, but collisions need handling), a counter with base-62 encoding (dense keys, but the counter is a single point of coordination), and pre-generated key ranges handed to servers (no hot spot, at the cost of a key-management service). There's no right answer — the comparison is the answer.
Common deep-dive territories worth having ready in any design: cache invalidation and TTL strategy, database partitioning and hot keys, replication and failover, rate limiting and abuse, and what happens when each component dies.
Phase 5: Wrap-up — trade-offs and evolution
End deliberately rather than trailing off. Three beats:
- Trade-offs made: "I chose availability over consistency on the redirect path; a just-created link might take seconds to work globally."
- Failure modes: what breaks first under 10x load, and what you'd monitor.
- Evolution: what you'd build differently at 100x scale, and what you'd deliberately not build yet.
This closing shows judgment — the actual competency the round measures.
The traps that sink strong engineers
- Diving straight into architecture. The most common failure. Boxes before requirements means impressive answers to unasked questions.
- The silent whiteboard. Long quiet stretches while you think read as being lost. Narrate your reasoning — the thinking is the deliverable.
- Depth-first collapse. Spending twenty minutes on one component before an end-to-end design exists. Breadth first, then depth.
- Buzzword architecture. Adding Kafka, or a queue, or "microservices" without a requirement forcing them. Every component you name is a component you can be grilled on.
- Ignoring steering. When the interviewer nudges — "what about failures here?" — that's not small talk; it's the rubric. Follow the nudge immediately.
Practicing the structure
The framework only helps if it's automatic under pressure, and that takes reps: pick classic prompts (URL shortener, rate limiter, news feed, chat), set a 45-minute timer, and talk through all five phases out loud — the out-loud part is not optional, because narrating while thinking is the skill being tested.
Interviewdom can support that practice loop: mock interviews include system-design rounds with scored feedback, and during a session it can generate architecture diagrams for the design you're discussing while suggesting the requirements-first structure this guide describes. However you practice, keep the invariant: requirements before boxes, breadth before depth, and a reason attached to every arrow.