A system design interview is not a quiz with one right answer. It is a 45-minute conversation where the interviewer watches how you think: do you clarify before you build, do you use numbers, do you make tradeoffs out loud? A repeatable structure keeps you calm and guarantees you cover what graders actually score.
This is the same six-phase timebox the System Design studio on this platform uses, so practice here transfers straight to the real thing.
0–5 Requirements & scope
5–13 Estimation & data model
13–25 High-level architecture & data flow
25–33 Deep dive #1 (the crux / bottleneck)
33–40 Deep dive #2 / failure handling
40–45 Tradeoffs, scaling limits, wrap-up
Treat these as soft budgets, not walls — but if you are 20 minutes in and still clarifying requirements, you are in trouble.
Phase 1 — Requirements & scope (0–5 min)
Never start drawing. First separate two kinds of requirements:
- Functional requirements — what the system does. "Users can post, follow others, and see a home timeline."
- Non-functional requirements (NFRs) — the qualities: scale, latency, availability, consistency, durability. "200M daily users, timeline under 200 ms, 99.9% available."
Ask clarifying questions and write the answers down as explicit assumptions:
- Who uses this, and how many? (daily active users)
- Is it read-heavy or write-heavy?
- How fresh must data be — is eventual consistency acceptable?
- Any hard constraints: mobile clients, regions, budget?
If the interviewer shrugs, state an assumption yourself: "I'll assume 100M DAU, read-heavy at about 100:1." That is leading the conversation.
Phase 2 — Estimation & data model (5–13 min)
Convert scale into back-of-the-envelope numbers: QPS (average and peak), storage per year, bandwidth. Even rough numbers change the design — 100 QPS fits on one box; 1M QPS does not.
Then sketch the data model: the key entities, their important fields, and the main access patterns (which queries run most often). The access pattern — not the entity list — decides whether you reach for a relational database, a key-value store, or a search index.
Phase 3 — High-level architecture (13–25 min)
Now draw the boxes: client, load balancer, stateless app servers, cache, database, queue, object storage, CDN. Keep it simple first; you can always add.
Then trace one request through the diagram out loud: "A write hits the load balancer, lands on an app server, which validates it, writes to the primary database, and publishes an event to a queue." Tracing a request exposes gaps faster than staring at boxes.
Phase 4 & 5 — Deep dives (25–40 min)
Pick the component that is genuinely hard for this problem — the fan-out for a feed, the index for search, the hot key for a counter — and go deep. The interviewer usually steers you here; follow their interest.
In deep dive #2, cover failure handling: what if the cache is cold, a shard is down, or the queue backs up? Mention retries, timeouts, replication, and graceful degradation.
Phase 6 — Tradeoffs & wrap-up (40–45 min)
Summarize the design in three sentences, restate the biggest tradeoff, and name the next bottleneck: "This scales to roughly X; beyond that I would shard by user_id and add read replicas."
Leading vs waiting
Drive the structure, but check in. Say what you are about to do ("Let me estimate QPS next"), make a decision, then ask "Does that match what you had in mind?" You own the structure; the interviewer steers the depth.
Common mistakes
- Jumping straight to technology ("I'll use Kafka and Cassandra") before requirements. Design follows requirements, not the reverse.
- No numbers. "It should be fast" means nothing; "p99 under 200 ms at 50k QPS" is a real constraint.
- Ignoring the interviewer. Silent monologues or steamrolling their hints both hurt — their questions are the rubric leaking out.
- Over-engineering. Do not add microservices, sharding, and multi-region on day one if the scale does not demand it.
Make the structure automatic and you free your brain for the actual problem.