S126 · System Design Framework — Reqs, Capacity, HLD, Deep-Dive
The four-step framework every FAANG interviewer scores against — how to structure a 45-minute system design round, when to push back, when to accept a number, and the anti-patterns that kill senior candidates in the first ten minutes.
🎯 Internalise the four-step system design framework (Reqs → Capacity → HLD → Deep-Dive) as a repeatable structure for the 45-minute interview and for real production design docs.
Why this session exists
System design is the highest-signal, highest-variance interview round at every senior engineering ladder — and the one candidates most commonly self-sabotage in the first five minutes by jumping to boxes before they know the problem. The framework here is not a hack for interviews; it is the same skeleton that every mature design doc at Google, Meta, Amazon and Microsoft follows internally. Learn the shape once and you use it for the rest of your career: at the whiteboard, in the doc, in the pre-launch review.
- Run a 45-minute system design round in four phases (Reqs · Capacity · HLD · Deep-Dive) with visible time discipline.
- Do a back-of-envelope capacity estimate that justifies architectural choices instead of decorating them.
- Draw an HLD in under 8 minutes that fits on one whiteboard and names its own trade-offs.
- Pick the right deep-dive component from interviewer cues instead of the one you happen to know best.
- Recognise the six anti-patterns that separate an L4 from an L5 answer to the same question.
Prerequisites
- S066 · Load Balancers (L4 vs L7, health-check basics)
- S070 · Sharding (shard keys, hot shards, resharding)
- S076 · Multi-Region (active-passive vs active-active, failover)
- S063 · Caching (cache-aside, TTL, invalidation)
(a) Intuition · 5 min
Think of a doctor at a first appointment. A junior doctor might see chest pain and immediately order every test the hospital owns. A senior doctor spends the first five minutes asking questions: onset, severity, when it started, what you were doing, family history. Only then do they order a targeted test.
The senior doctor is not slower — they are faster at ruling out the wrong path. The system design interview is exactly that dynamic. The candidate who reaches for Kafka in minute two is the junior doctor ordering an MRI for a bruise.
A 45-minute system design round has four beats: clarify the problem, estimate the scale, draw a high-level design, zoom in on one or two components. Each beat has a rough budget (5 · 5 · 10 · 20 minutes with 5 for wrap-up).
The interviewer is not scoring your architecture. They are scoring whether you can drive a design conversation under uncertainty — asking, quantifying, deciding, defending. The framework is the visible signal that you can.
- There is no right answer — only trade-offs you can defend for three follow-up questions.
- Every architectural choice must be justified by a number you produced in the estimation phase.
- The framework's four steps are not padding — skipping any one of them is the fastest way to lose the round.
- Level differentiation (L4 vs L5 vs L6) is about how deeply you can zoom in and how many failure modes you anticipate — not about how many buzzwords you deploy.
- 2015Grokking the System Design Interview launchesFirst widely-shared prep resource; standardises the vocabulary interviewers expect (fanout, sharding, consistency).
- 2020Alex Xu · System Design Interview Vol 1Canonicalises the four-step framework used in this session. Becomes the most-cited prep book at FAANG.
- 2021ByteByteGo video seriesFree companion videos push the framework mainstream; interviewers now expect candidates to know it.
- 2023Interview format convergesMeta, Google, Amazon, Microsoft, Netflix all publish rubrics that map cleanly to the same four phases.
- 2025AI-assisted prep changes signalInterviewers now weight live reasoning and clarification depth even more heavily because model-generated answers are trivially memorisable.
(b) Visual walkthrough · 15 min
The 45-minute round has a fixed budget. Miss a phase and you leave signal on the table — but drift into a phase for too long and you starve the deep-dive, which is where the strongest signal is scored.
Users, use cases (top three), read/write ratio, latency SLA, consistency needs, explicit non-goals.
Peak QPS, storage growth, bandwidth, cache-hot-set size. Every number will justify a box you draw in Phase 3.
Clients → LB → API tier → data stores. Boxes and arrows only. Name the shard key, cache tier, and async paths as you draw.
Interviewer steers. Pick one or two components and go three layers deep — data model, consistency, failure modes.
Call out known bottlenecks, sketch what you would build next, list the trade-offs you deliberately chose.
Worked example — "Design Twitter"
Phase 1 · Clarify. You say: "Before I dive in — can I confirm the scope?" Then walk through:
- Users? "1 B total, 200 M daily active."
- Actions? "Tweet (280 chars), follow, view home timeline."
- Read/write ratio? "~100 : 1, read-heavy."
- Consistency? "Eventual for the timeline, strong for tweet creation."
- Non-goals? "DMs, ads, search — out of scope for this round."
Phase 2 · Estimate. Speak the arithmetic out loud:
- 200 M DAU × 2 tweets/day / 86 400 s ≈ 5 k tweets/sec average, ~15 k/sec peak.
- Timeline reads: 200 M × 20 opens/day ≈ 50 k QPS average, ~150 k/sec peak.
- Storage: 15 k tweets/sec × 300 B × 86 400 × 365 ≈ 150 TB/year just for tweet text.
Now you have a reason to shard, a reason to cache, and a reason to fan out asynchronously — before drawing a single box.
Phase 3 · HLD. Draw only what your numbers demand:
Phase 4 · Deep-dive. The interviewer says "let's talk about the timeline." You pivot:
- Fanout on write (push to each follower's Redis timeline when someone tweets) vs fanout on read (assemble the timeline from followees when the user opens the app).
- Hybrid: fanout-on-write for normal users, fanout-on-read for celebrities. Bieber has 100 M followers — writing 100 M cache entries per tweet destroys the fanout tier.
- Cache eviction: LRU per-user timeline of ~800 tweets; rebuild from the tweet store on miss.
Phase 5 · Wrap-up. "I'd design search next, and the biggest risks I see are celebrity fanout and hot shards on trending hashtags." Ten seconds. Land the plane.
Component vocabulary — the shortlist worth memorising
Kubernetes + horizontal autoscaler; every pod interchangeable.
- Scales linearly with QPS.
- No local state — sessions in Redis, files in S3.
- Blue-green or canary rollouts trivially safe.
Redis or Memcached in front of the primary store.
- Cache-aside is the default pattern (S063).
- Watch for stampedes on hot keys.
- Choose TTL and eviction jointly with the freshness SLA.
Postgres or MySQL sharded by the primary access key.
- Strong consistency, transactions, joins.
- Vertical scale first; shard when writes exceed one node.
- Read replicas for read fanout; watch replication lag.
Cassandra or DynamoDB for very large keyspace.
- Great for time-series, event logs, user graphs.
- No joins — model for the query.
- Tunable consistency (quorum reads/writes).
Kafka, SQS, Kinesis for events and fanout.
- Keeps the request path fast.
- Absorbs bursty writes.
- Enables replay for analytics and reprocessing.
S3, GCS, Azure Blob for anything big or immutable.
- Cheap durability at scale.
- CDN in front for public assets.
- Signed URLs for private access.
How the phases stack — what each layer must justify
"System design interviews are about knowing the right architecture. If I memorise enough reference designs — URL shortener, chat, newsfeed — I can pattern-match my way through any question."
The evaluation is of your process, not your recall. Two candidates can draw the same boxes and get opposite outcomes: one derived the design from requirements and stated what each choice cost, the other asserted it. The strongest signal you can give is quantifying scale first and letting the numbers eliminate options — because that is what distinguishes someone who has designed a system from someone who has read about one.
Because the artefact produced is a diagram, and diagrams are what you see in write-ups and blog posts. The reasoning that produced them is invisible, so it is not what you study. It is also true that a wrong architecture fails the interview — so the myth is half-right, which is the worst kind: pattern-matching gets you to a plausible design and then collapses on the first follow-up question about a constraint the reference design did not have.
Self-test any design you produce with three questions the interviewer will ask:
1. WHY this component and not the obvious alternative?
Answer must name a requirement, not a preference.
2. What BREAKS FIRST as traffic grows 10x?
If you cannot name a specific component and metric,
you have not sized anything.
3. What did this choice COST?
Every choice costs something. 'Nothing' means you
have not understood the choice.If any answer is "because that's the standard approach", you have pattern-matched rather than designed.
Why does back-of-envelope estimation come before drawing any architecture? It feels like arithmetic busywork when the clock is running.
- 1Architectural choices are only distinguishable by their behaviour at a particular scale. A single Postgres instance and a sharded distributed store are equally correct designs — for different numbers.forced by · every technology has an operating range, and correctness is relative to where you sit in it
- 2So without a number, no choice between them can be justified — you are choosing on familiarity rather than on fit.forced by · the discriminating variable has not been established
- 3The numbers also eliminate whole branches instantly. If total storage is 500 GB, sharding is off the table and the entire distributed-consistency discussion is unnecessary. If it is 5 PB, single-node is dead and so is anything requiring a full scan.forced by · an order-of-magnitude estimate is enough to rule options in or out, even if it is off by 3×
- 4They further reveal which dimension actually binds. Reads per second, writes per second, storage growth and fan-out are independent, and systems fail on exactly one of them first.forced by · bottlenecks are singular; the binding constraint determines the design
- 5And the read:write ratio in particular determines the entire shape — a 100:1 read-heavy system wants caching and replicas, while a write-heavy one wants partitioning and an append-optimised store. These are opposite architectures.forced by · caching helps reads and does nothing for writes; partitioning helps writes and complicates reads
Therefore estimation is not preliminary arithmetic — it is the step that converts an open-ended question into a constrained one with a small number of viable answers.
And note what this predicts: the most valuable estimate is whichever one changes your design. If a number would not alter any decision, computing it is theatre. So the disciplined move is to ask "what would I do differently if this were 10× larger?" — and if the answer is nothing, skip it and estimate something else. That is also the fastest way to find the dimension that actually matters.
A design interview is a funnel from an ambiguous prompt to a defended architecture: Requirements → Estimation → Storage/API → High-level design → APIs → Detailed design → Evaluation → Distinctive features.
The numbers from step two are what justify every arrow after it. If you can trace each component back to a requirement or an estimate, the design defends itself; if you cannot, every follow-up question is a threat.
- Scope aggressively in the first five minutes. "Which of these do you want me to focus on?" is a senior signal, not a stall.
- Non-functional requirements decide the architecture more than functional ones. Latency budget, consistency requirement, availability target and durability tolerance are the real inputs.
- State tradeoffs out loud, unprompted. "I'm choosing X, which costs us Y; I'd revisit if Z" is the single highest-value sentence in the interview.
- Drive the conversation. Silence while thinking is fine; silence while drawing is a missed signal.
Fire this framework the moment you see: any open-ended "design X" prompt · a design review at work · an architecture doc with no numbers in it · a technology choice justified by popularity · a proposal that does not say what it gave up.
Forty-five minutes, an ambiguous prompt. Go broad across the whole system, or deep on the hardest component?
Sketch the whole system in roughly ten minutes, then say explicitly: "the hard part here is X because of the numbers we computed — I'd like to go deep there." That single sentence demonstrates estimation, prioritisation and judgement at once, and it puts you in control of which ground the rest of the interview is fought on.
The same discipline transfers directly to design docs at work, which is why it is worth internalising rather than rehearsing: a document that names the binding constraint and defends one deep decision against alternatives is more useful than one that describes every component evenly.
(c) Hands-on · 25 min
System design is a whiteboard skill — the best "hands-on" is to drill the framework end-to-end against real problems on a timer. Below is the template that scores well in a real loop. Fill it in three times this week, one problem per drill: URL shortener, chat, newsfeed. Record yourself on the third one.
# System Design Drill · <PROBLEM NAME>
# Timer: 45 minutes. Do not stop the clock.
## Phase 1 · Clarify (5 min)
- **Top 3 use cases the design must serve:**
1.
2.
3.
- **Users / MAU / DAU (given or assumed):**
- **Read : Write ratio:**
- **Consistency requirement:** eventual / strong / hybrid
- **Latency SLA:** e.g. p99 < 200 ms redirect, p99 < 800 ms feed
- **Explicit non-goals (say them out loud):**
## Phase 2 · Estimate (5 min) — speak the arithmetic
- Peak QPS = _____ users × _____ actions/day / 86400 = _____ req/s
- Storage growth = _____ bytes/record × _____ records/day = _____ GB/day
- 5-year storage = above × 365 × 5 = _____ TB
- Egress bandwidth = _____ MB/s average, _____ MB/s peak
- Hot cache working-set = _____ GB (justify the number)
## Phase 3 · HLD (10 min) — one whiteboard
- Client → LB → API tier → data stores
- Which tiers are stateless? (mark them)
- Which paths are async / queue-backed? (mark them)
- Primary store, shard key, cache tier, CDN?
- Draw arrows with protocol (HTTP, gRPC, Kafka topic, WebSocket)
## Phase 4 · Deep-Dive (20 min) — pick 1 or 2
Choose based on interviewer cues. Common deep-dive angles:
- **Data model + shard key** — what is the partition key? Hot-shard risk?
- **Consistency model** — read-your-writes? monotonic reads? cross-region?
- **Caching strategy** — cache-aside vs write-through; TTL; stampede protection.
- **Failure modes** — DB down? whole AZ down? cache cold-start?
- **Rate limiting & abuse** — how do you cap one user blowing everything up?
- **Observability** — three metrics you would alert on, one dashboard you would build.
## Phase 5 · Wrap-Up (5 min)
- Known bottlenecks I have not solved:
- Next thing I would design (and why):
- Trade-offs I deliberately made (list at least 3):Anatomy of the drill — what each line is training
# Photo-Sharing App · 45-min drill
Phase 1 · Clarify
- Top 3 use cases: upload photo, view feed, follow user
- Users: 100 M MAU / 40 M DAU
- Reads : writes = ~100 : 1
- Consistency: strong on upload success, eventual on feed
- SLA: upload p99 < 3 s, feed p99 < 500 ms
- Non-goals: DMs, stories, video, ads
Phase 2 · Estimate
- 40 M DAU × 0.5 uploads/day / 86 400 ≈ 230 uploads/s avg, ~1 k peak
- Storage: 1 k × 1 MB × 86 400 × 365 ≈ 30 PB/year of original photos
- Feed reads: 40 M × 20 opens/day ≈ 9 k QPS avg, ~30 k peak
- Cache hot-set: top 1 M users × 200 feed items × 1 KB ≈ 200 GB
Phase 3 · HLD (draw!)
- Client → CDN (for photo bytes) → LB → API tier
- Upload path: API → S3 (photo) + Postgres (metadata, sharded by user_id)
- Read path: API → Redis (feed cache) → on miss → Postgres + S3
- Fanout: Kafka → workers write to Redis feed lists
- Observability: metrics tier fed by API + workers
Phase 4 · Deep-dive
(interviewer will pick — practise both fanout AND upload path)
Phase 5 · Wrap-up
- Bottlenecks: celebrity fanout, S3 egress cost, cold-start feed
- Next: search, moderation pipeline
- Trade-offs: eventual feed for cache hit rate; sharded Postgres for
simpler ops instead of Cassandra(d) Production reality · 15 min
A candidate with 12 years of experience was asked to design a URL shortener. Confident opener: "I'd build this on Kubernetes with a service mesh, event sourcing, and CQRS for the read models."
Twenty minutes in, the interviewer asked "what QPS are we designing for?" The candidate had never asked. The actual scope in the interviewer's mind was a 100 QPS internal tool.
Rejection came inside 24 hours. Feedback: "Candidate demonstrated inability to calibrate solution complexity to problem complexity."
The framework's Phase 1 exists specifically to prevent this. Five minutes of clarifying questions would have surfaced the actual scope and saved the round.
Candidate designing a distributed cache confidently proposes "we'd use Raft for consensus." Interviewer asks the natural follow-up: "why Raft and not Paxos, and what does Raft actually give you here?"
The candidate could not explain what Raft solves at more than a Wikipedia summary depth. The interviewer scored the round as "vocabulary without understanding."
Only mention tech you can defend for three follow-up questions. If Raft, you must be able to sketch leader election, log replication and safety. If Kafka, you must be able to sketch partitions, consumer groups and delivery semantics.
Otherwise, use the more honest phrasing: "I would want a consensus store here — Raft or Paxos — and I would pick based on the operational familiarity of the team." That is a senior answer.
Candidate given "design a distributed rate limiter." Spends 15 minutes on the algorithm (token bucket vs leaky bucket vs sliding window). Never asks about scale, never draws a system diagram, never talks about failure modes.
Interviewer's note: "Deep on one component, blind on the system. This is a mid-level answer, not a senior one."
Every phase gets a budget. Even if you love a topic, do not spend Phase 3 (HLD) time inside Phase 4 (deep-dive). Draw the whole system first — even a wrong system on the board is more scorable than a perfect algorithm in isolation.
If you catch yourself sliding past Phase 3, say out loud: "Let me park this and come back after the HLD." That single sentence recovers the round.
Common failure modes
Where this shows up in the rest of the plan
Level differentiation — what interviewers actually score
Can draw a correct HLD when prompted; knows the vocabulary.
- Needs the interviewer to steer through phases.
- Estimates when reminded; otherwise skips.
- Deep-dive is competent on 1 component if it happens to be a known one.
Drives the interview. Structures phases unprompted.
- Asks clarifying questions before drawing anything.
- Produces numbers out loud with visible arithmetic.
- Articulates trade-offs on every choice.
- Handles at least one deep-dive well end-to-end.
Compares architectures with a trade-off table.
- Anticipates failure modes two steps out.
- Names organisational + on-call implications, not just tech.
- Asks whether the framed problem is the right problem to solve.
- Recovers gracefully when the interviewer pivots mid-round.
(e) Recall + stretch · 10 min
Explain-out-loud test
If you cannot teach these three things to a friend without notes, redo the session:
- The four phases and their budgets — in order, with a one-line goal each.
- Why the framework is scored, not the answer — one sentence on what an interviewer is actually measuring.
- The six anti-patterns — you should be able to name at least four out loud.
Part of a 130-session evergreen learning series. Session structure: (a) intuition · (b) visual walkthrough · (c) hands-on · (d) production reality · (e) recall + stretch. Duration: 90 minutes.