S126 · System Design Framework — Reqs, Capacity, HLD, Deep-Dive

Module M15: System Design · Session 126 of 130 · Track: SYS 🏛️

What you'll be able to do after this session

• Explain System Design Framework to a friend in one minute, out loud, no notes.
• Recognise it when you see it in real code / systems / papers.
• Complete the hands-on exercise at the end without looking up help.

Prerequisites

If you can't answer these in 30 seconds each, redo the linked session first:

• S076 — Multi-Region — Active-Passive, Active-Active, Failover

Pre-read (skim before the session)

• 🎥 Intuition (5–15 min) · System Design Interview Basics — Exponent's 12-min overview of the interview flow.
• 🎥 Deep dive (30–60 min) · System Design Interview: A Step-by-Step Guide — full framework walkthrough with example.
• 🎥 Hands-on demo (10–20 min) · Mock System Design Interview — Google engineer runs a real mock.
• 📖 Canonical article · The System Design Primer — the most-starred systems design reference on GitHub.
• 📖 Book chapter / tutorial · ByteByteGo — System Design Interview Framework — Alex Xu's 4-step framework, distilled.
• 📖 Engineering blog · High Scalability — Real World Architectures — indispensable archive of how real systems (Netflix, Uber, Instagram) were designed.

(a) Intuition · 5 min

The one-paragraph mental model. Why this concept exists, what problem it solves, and the analogy that makes it stick.

In one sentence: How to structure a 45-min interview.

A system design interview is not a test of whether you know every buzzword; it's a test of whether you can have a structured conversation under uncertainty. Junior candidates dive into "let's use Kafka and Redis and Kubernetes" in minute two. Senior candidates spend the first 10 minutes asking questions, then draw a boring HLD (high-level design), then get interesting only when the interviewer starts probing trade-offs. The framework matters more than the answer — because there is no single right answer.

The industry-standard four-step framework (popularised by Alex Xu, used at Google, Meta, Amazon interviews) is: (1) Understand & scope — clarify requirements, users, scale, must-haves vs nice-to-haves. (2) Back-of-envelope capacity estimation — QPS, storage, bandwidth. Not to be precise, but to justify architectural choices ("we need sharding because 500 TB doesn't fit on one box"). (3) High-level design — draw boxes: clients, load balancer, app servers, database, cache. Should fit on one whiteboard. (4) Deep-dive — pick one or two components the interviewer cares about and go deep: sharding strategy, cache eviction, consistency model, failure modes.

The gotcha you must carry forever: the interviewer is not looking for the "correct" architecture — they are looking for evidence you can reason about trade-offs. If you say "I'll use MongoDB", the good interviewer asks "why not Postgres?" The bad answer: "because MongoDB is fast". The good answer: "our access pattern is single-document reads on a natural key, we don't need joins, and we expect 100k+ writes/sec — Mongo's sharding story is simpler for our use case. Postgres could work too if we accepted more ops complexity around Citus or manual sharding." Always articulate what you're trading away.

(b) Visual walkthrough · 15 min

Diagrams, worked examples, step-by-step visuals.

The 45-minute interview budget, broken down:

Worked example — you're asked to design Twitter:

Phase 1 (Clarify — 5 min):

• Users? "1B total, 200M daily active."
• Actions? "Tweet (280 chars), follow, view timeline."
• Read/write ratio? "100:1 read-heavy."
• Consistency? "Eventual OK for timeline; strong for tweet creation."
• Out of scope? "DMs, ads, search."

Phase 2 (Estimate — 5 min):

• 200M DAU × 2 tweets/day / 86400s ≈ 5k tweets/sec peak ~15k/sec.
• Timeline reads: 200M × 20 loads/day ≈ 50k QPS peak ~150k QPS.
• Storage: 15k tweets/sec × 300 bytes × 86400 × 365 ≈ 150 TB/year just for tweet text.

Phase 3 (HLD — 10 min):

Phase 4 (Deep-dive — 20 min): interviewer says "let's talk about the timeline". Now you go deep:

• Fanout on write (push to followers' Redis timelines when they tweet) vs fanout on read (assemble timeline from followees when user opens app).
• Hybrid: fanout-on-write for normal users, fanout-on-read for celebrities (Justin Bieber has 100M followers — writing 100M cache entries per tweet is insane).
• Cache eviction: LRU per-user timeline of ~800 tweets. Rebuild from tweet store on miss.

Phase 5 (Wrap — 5 min): mention what you'd design next (search, DMs, analytics), acknowledge bottlenecks (celebrity fanout, hot shards).

Component vocabulary (memorise these):

(c) Hands-on · 20 min

Code you type and run. Not pseudo-code — real, runnable, copy-pasteable.

System design is a whiteboard skill. The best "hands-on" is to actually run through a design end-to-end. Below: a structured template you can fill in for any problem in exactly 45 minutes. Do this drill for 3 different problems this week.

# System Design Drill Template · <PROBLEM NAME>
 
## 1. Clarify (5 min) — write answers here
 
- **Core use cases (top 3):**
  1.
  2.
  3.
- **Users / QPS estimate the interviewer gave (or you assumed):**
- **Read/write ratio:**
- **Consistency requirement:** eventual / strong / hybrid?
- **Latency SLA:** e.g. p99 < 200ms
- **Out of scope:**
 
## 2. Estimate (5 min)
 
- QPS (peak): _______ × _______ = _______ req/sec
- Storage growth: _______ bytes/record × _______ records/day = _______ GB/day
- Bandwidth (egress): _______ MB/sec average, _______ peak
- Cache size needed to hold hot set: _______ GB
 
## 3. HLD (10 min) — draw the boxes
 
- Client -> LB -> [what tier?] -> [what data store?]
- Which components need to be stateless?
- Which parts are async (queue) vs sync (RPC)?
- Where do reads go vs writes go?
 
## 4. Deep-dive (20 min) — pick 1-2
 
Pick based on interviewer cues. Common deep-dive angles:
 
- **Data model & sharding key** — what's the partition key? What are hot-shard risks?
- **Consistency model** — read-your-writes? monotonic reads? cross-region?
- **Caching strategy** — write-through, write-back, cache-aside? Eviction?
- **Failure modes** — what happens if the database goes down? A whole AZ?
- **Rate limiting & abuse** — how do you prevent one user from blowing everything up?
- **Observability** — 3 metrics you'd alert on, 1 dashboard you'd build.
 
## 5. Wrap-up (5 min)
 
- Known bottlenecks in your design:
- What would you build next / how would you evolve?
- Trade-offs you deliberately made:

Observe as you drill:

1. Time yourself with a phone timer. You'll blow phase 4 the first 3 times. That's normal.
2. You will not fill the whole template first time — that's the point. Notice which phases you rush.
3. Watch yourself over-index on one component you know well (e.g. Kafka) — resist. Cover the whole system first.
4. Record yourself talking through the drill (audio only). Play back — you'll hear filler words and unclear reasoning you couldn't self-detect live.
5. After each drill, spend 5 min journalling: what would you do differently next time?

Try this modification: run the same problem with two constraints. First pass: "10k users, single region". Second pass: "1B users, global multi-region". Notice how the boxes on the HLD diagram change — CDN appears, geo-DNS appears, multi-region replication appears, conflict resolution appears. That transformation is what interviewers are testing.

(d) Production reality · 10 min

How this shows up in real systems, gotchas, war stories, common bugs.

War story — the "I built Netflix on my laptop" candidate. A senior candidate at a FAANG interview jumped straight into designing a "microservices architecture with service mesh, event sourcing, and CQRS" for a URL shortener. 20 minutes in, the interviewer asked "how many QPS are we designing for?" — the candidate had never asked. Turned out the actual requirement was 100 QPS internal-tool scale. Rejection came within 24 hours: over-engineering is worse than under-engineering because it signals you can't calibrate to context.

Common gotchas top interview candidates handle for:

• Don't propose exotic tech unprompted — mentioning "we'd use a Raft-based consensus store" when you can't articulate what Raft actually solves gets you buried. Only mention tech you can defend for 3+ follow-up questions.
• Don't invent QPS numbers with false precision — "12,847 requests per second" makes you sound like a fraud. Say "~10-15k" and show the math.
• Don't skip the estimation step — many candidates try to look "senior" by going straight to boxes. Estimation is how you justify which box you drew.
• Don't argue with the interviewer — if they say "let's assume 1M users", don't push back with "but realistically it'd be 10k". Take the number, run with it.
• Do call out what you're NOT doing — "I'm not going to design auth in detail because you said out of scope" earns points; it shows you're being deliberate.
• Do quantify trade-offs — instead of "this is faster" say "this reduces P99 read latency from ~50ms (DB hit) to ~2ms (cache hit) at the cost of ~10s of stale data".

Level differentiation (what separates L4 → L5 → L6 in this interview):

• L4 / mid: can draw a correct HLD with prompting, knows the vocabulary.
• L5 / senior: drives the interview, asks clarifying questions, articulates trade-offs unprompted, handles one deep-dive well.
• L6 / staff: proposes multiple architectures with a clear "here's the trade-off table between them", anticipates failure modes 2 steps out, discusses org / operational implications ("this design needs an on-call rotation with X SLO"), and asks whether the whole problem is even the right problem to solve.

Every FAANG interview loop has at least one system design round. It's the highest-signal, highest-variance round. Practice the framework on 15+ problems (URL shortener, chat, newsfeed, ride-share, ad system, distributed cache, video streaming, notification service) before your loop.

(e) Quiz + exercise · 10 min

1. What are the four canonical steps of the system design interview framework, in order?
2. Why is back-of-envelope capacity estimation done before drawing the high-level design?
3. Give three phrases you can say that shift a design conversation from "I know this tech" to "I understand the trade-offs".
4. Fanout-on-write vs fanout-on-read — describe when each is appropriate, and why hybrid approaches exist.
5. What signals distinguish a mid-level from a senior candidate in this interview, per FAANG rubric?

Stretch problem (connects to S076 — Distributed Systems): Take any distributed-systems concept you learned in S076 (Raft, Paxos, CAP, quorum reads, vector clocks). Explain how you would introduce it into a system-design answer without sounding like you're name-dropping — i.e. what question does the interviewer have to be asking for that concept to naturally come up?

Explain-out-loud test

If you can't teach these 3 things to a friend without notes, redo the session:

1. What is System Design Framework? (one sentence, no jargon)
2. When would you use it? (one concrete example)
3. When would you NOT use it? (one anti-pattern)

What comes next

• Next session (S127): Design a URL Shortener — the Classic Warm-Up
• Previous (S125): Multimodal LLMs — CLIP, VLMs, Audio, Video
• Hub: The 6-Month Learning Plan

Part of a 130-session evergreen learning series. Session structure: (a) intuition · (b) visual walkthrough · (c) hands-on · (d) production reality · (e) quiz + exercise. Duration: 60 minutes.