Concept 12: The System Design Interview Playbook — Method, Numbers & Estimation

System Design Bible — Bonus File 12 (The Capstone Meta-Skill) Difficulty: ★★★★☆ Why this file exists: Files 01–11 gave you the building blocks. This file gives you the method to assemble them into an answer under pressure — a repeatable step-by-step framework, the back-of-the-envelope numbers every senior engineer has memorized, and battle-tested templates. Concepts without a method is a toolbox without hands.

Table of Contents#

0Prerequisites — The Mindset#

Before any framework, internalize three truths about what this interview is, because they change how you behave in the room.

0.1It is a conversation, not a monologue or an exam#

The system design interview is collaborative and open-ended by design. There is no single correct answer — a URL shortener can be built ten defensible ways. The interviewer is playing the role of a teammate/stakeholder you're designing with, and they will deliberately leave the problem vague ("Design Twitter") to see whether you ask clarifying questions, state assumptions, and drive the discussion — or whether you freeze, or charge ahead building the wrong thing. Candidates who treat it like a lecture ("here is my complete design") do worse than those who think out loud, check in ("does this scope sound right?"), and adapt to the interviewer's nudges. Talk continuously, reason visibly, and treat every interviewer comment as a signal to steer toward. Silence and rigidity are the enemies.

0.2They are hiring your judgment about trade-offs, not your memory of architectures#

Anyone can memorize "use Kafka and Cassandra." What separates a hire from a no-hire is **articulating why, and what you're giving up.** Every single decision in this bible came with a trade-off (that's why every file has a Pros/Cons section). The interview is fundamentally a test of whether you can say "I'll use a cache here — it cuts read latency ~100× and offloads the DB, but I'm now accepting eventual consistency and I'll need to handle invalidation and stampede." That sentence — decision + benefit + explicit cost + mitigation — is the atomic unit of a senior answer. Never state a component without its trade-off. A design presented as if it has no downsides signals you don't understand it.

0.3Drive from requirements → scale → design, never design-first#

The single most common failure is jumping straight to boxes and arrows before understanding what's being built or how big it is. The correct causality is: requirements determine scale numbers, and scale numbers determine which architecture is justified. A system doing 100 requests/day needs a single server and a SQLite file; the same feature at 1 million requests/second needs sharding, caching, CDN, and queues. If you design before estimating, you either massively over-engineer (drawing a 12-service architecture for a problem a monolith solves — a red flag for senior roles) or under-engineer (a single database for Twitter's write volume). The numbers tell you how much machine the problem deserves. This is why estimation (§4) sits before deep design in the framework.

1What the Interviewer Is Actually Measuring#

They're scoring you on a rubric — know it so you can deliberately hit each dimension:

Notice: raw architecture is only one of six. Trade-off reasoning, scale justification, and communication carry the interview — which is exactly why memorizing this bible's Pros/Cons and Symptom→Solution sections matters more than memorizing diagrams.

2The 6-Step Framework (RADIOS)#

A repeatable structure so you never freeze. Budget your ~45 minutes across it.

(Do the estimation as the bridge between R and A — see §3.2. Some frameworks call this RESHADED or the "4-step"; the names don't matter, the sequence does: understand → quantify → sketch → stress → deepen → recap.)

3Step-by-Step, In Depth#

3.1Step R — Requirements (5 min, the step that saves you)#

Split into two kinds, and be explicit about both:

Functional requirements — what the system does (features, verbs). For "design Twitter": post a tweet, follow users, view a home timeline, like. Ruthlessly scope down — the interviewer offered a giant problem to see if you'll narrow it. Say: "There's a lot here. Let me focus on posting tweets and generating the home timeline as the core, and treat search, DMs, and notifications as out of scope unless you'd like me to cover them — sound good?" This single move (proposing scope and confirming) is a strong early signal.

Non-functional requirements — the qualities the system must have; these are what actually drive the architecture:

Write these on the board. They are your rubric for every later decision — every choice should trace back to a requirement.

3.2The Bridge — Estimation (do it here, ~3–5 min)#

Now turn requirements into numbers (full method in §4). You need, roughly:

State assumptions out loud ("assume 100M DAU, each posts 2 tweets/day…"). The interviewer cares about method and sanity, not precision — round aggressively. These numbers justify everything next: "at 1M write QPS, a single database can't take the writes, so we shard" is a far stronger statement than "let's shard because scale."

3.3Step A — API + Data Model (5 min)#

API: define the handful of core endpoints as clean contracts — method, path, params, response. E.g. POST /tweets {text} → {tweet_id}; GET /timeline?user_id&cursor → [tweets]. Note pagination (cursor-based, not offset, at scale) and idempotency keys for writes that must not double-execute (File 07). This shows you think in interfaces.

Data model: the core entities and their relationships — User, Tweet(id, author_id, text, created_at), Follow(follower_id, followee_id). Naming the entities and their keys sets up the sharding discussion (File 04: what's the shard key?) and the SQL-vs-NoSQL discussion (File 11). Decide, per entity, roughly where it lives (relational? KV? wide-column?) and why.

3.4Step D — High-Level Diagram (10 min)#

Draw the end-to-end happy path, left to right: Client → DNS → Load Balancer → API servers (stateless) → {Cache, Databases} + async workers via Queue. Start simple and correct — a working single-region design that satisfies functional requirements — before scaling it. Talk through one request's full journey. Keep app servers stateless (File 01) so they scale horizontally; put session/hot state in a shared cache (File 02). This is the skeleton you'll now stress-test.

3.5Step I — Identify Bottlenecks & SPOFs (5 min)#

Proactively hunt the pressure points before the interviewer asks (doing this unprompted is a senior signal):

Say them out loud: "The database read path is the first bottleneck, and this single primary is a SPOF — let me address both."

3.6Step O — Optimize / Deep-Dive (15 min, where you win)#

Now systematically apply the bible to each bottleneck. This is the longest, most important step — the interviewer will usually pick one area and go deep, so be ready to zoom into any of:

For each fix, state the trade-off (§0.2 format). If they deep-dive a component, go two more levels down (e.g., cache → which eviction policy → how you handle the thundering herd).

3.7Step S — Summarize (5 min)#

Recap the design end to end, restate how it satisfies each requirement, name the key trade-offs you made, call out the remaining weak spots / SPOFs, and say what you'd do with more time (multi-region, better observability, cost optimization). This leaves a "senior, self-aware" final impression — you know your design isn't perfect and you know exactly where.

4Back-of-the-Envelope Estimation#

The method that makes your scale claims credible. The goal is a sanity-checking approximation in under 5 minutes, not accuracy — round everything to powers of 10.

4.1The Powers-of-Ten Table (memorize)#

Thousand      = 10^3   (KB)
Million       = 10^6   (MB)
Billion       = 10^9   (GB)
Trillion      = 10^12  (TB)
Quadrillion   = 10^15  (PB)

And the time anchor: ~100,000 seconds per day (86,400, round to 10^5). This one number turns "per day" into "per second" instantly: X per day ÷ 10^5 ≈ X per second... /100k. (1 million/day ≈ 10 QPS. Remember it.)

4.2The Four Quantities & How to Derive Each#

(1) QPS (traffic).

avg QPS = daily requests / 100,000
peak QPS ≈ avg QPS × (2 to 3)      [traffic isn't uniform; size for peak]

Example: 100M DAU × 10 reads/day = 1B reads/day ÷ 10^5 = 10,000 avg read QPS, ~25,000 peak.

(2) Storage.

storage/day = items/day × bytes/item
total = storage/day × retention_days   (then × replication factor, usually 3)

Example: 500M tweets/day × 300 bytes = 150 GB/day → ×5 years ≈ 270 TB → ×3 replication ≈ ~800 TB. (This is why you shard.)

(3) Bandwidth.

egress = read QPS × response_size

Example: 25,000 QPS × 1 KB = 25 MB/s (fine); but 25,000 QPS × 2 MB (video) = 50 GB/s → that's why you need a CDN (File 05), not your origin.

(4) Memory (cache sizing).

cache size ≈ (hot fraction of data) held in RAM   [Pareto: ~20% of data serves ~80% of reads]

Example: to cache the day's hot tweets: if 20% of 150 GB/day is hot ≈ 30 GB → fits comfortably in a Redis cluster, huge DB offload.

4.3The Ratios That Steer Architecture#

5The Numbers You Must Memorize#

5.1Latency Numbers Every Engineer Should Know (the canonical list)#

L1 cache reference ........................... 0.5 ns
Branch mispredict ............................ 5   ns
L2 cache reference ........................... 7   ns
Mutex lock/unlock ............................ 25  ns
Main memory (RAM) reference .................. 100 ns      <- the "fast" baseline
Compress 1 KB ................................ 3,000 ns (3 µs)
Send 1 KB over 1 Gbps network ................ 10,000 ns (10 µs)
Read 1 MB sequentially from RAM .............. 250,000 ns (250 µs)
Round trip within same datacenter ............ 500,000 ns (0.5 ms)
Read 1 MB sequentially from SSD .............. 1,000,000 ns (1 ms)
Disk seek (HDD) .............................. 10,000,000 ns (10 ms)
Read 1 MB sequentially from disk (HDD) ....... 20,000,000 ns (20 ms)
Round trip CA <-> Netherlands ................ 150,000,000 ns (150 ms)

**What to derive from these (the point of memorizing them):**

5.2Capacity Rules of Thumb (rough, for sanity)#

~86,400 s/day  ->  round to 10^5           (X/day / 100k = X/sec)
Single commodity server:  handle ~1,000s–10,000s of simple QPS (varies wildly by work)
Single SQL DB (well-tuned): comfortably ~1,000s of writes/s, ~10,000s of reads/s (then shard/replicate)
Redis single node:         ~100,000+ ops/s
Kafka:                     ~millions of msgs/s (a cluster)
One modern server RAM:     up to ~100s of GB – few TB
One disk (SSD):            up to ~tens of TB
Availability nines:  99.9% = ~8.7 h/yr down | 99.99% = ~52 min/yr | 99.999% = ~5 min/yr

Use these to say things like "one Postgres tops out around a few thousand writes/sec, and we need 50k, so we shard into ~16." That's a credible, numbers-driven justification.

5.3Handy Size Anchors#

char/int ~ 1–8 bytes | UUID ~16 B | typical tweet/row ~ 100s of bytes–1 KB
web page ~ 100 KB–2 MB | photo ~ 100 KB–a few MB | minute of video ~ 10s of MB

6Reusable Design Templates#

Most problems are variations on a few skeletons. Recognize the pattern, adapt the template.

6.1The Read-Heavy Feed/Timeline (Twitter, Instagram, News)#

Client → CDN (media) → LB → stateless API → Redis (timeline cache) → sharded DB

6.2The Write-Heavy Ingestion (metrics, logs, IoT, messaging)#

Producers → Kafka (buffer/decouple) → stream processors → LSM store (Cassandra) + OLAP warehouse

6.3The Transactional System (payments, orders, bookings)#

Client → LB → API → relational DB (ACID) + cache; async side-effects via queue; cross-service = Saga

6.4The Global Low-Latency Static/Media System (video, images, downloads)#

Users → GeoDNS/Anycast → CDN edges → origin shield → object storage (S3)

6.5The Proximity/Geo System (ride-hailing, "nearby", maps)#

7How the 11 Concepts Map to Symptoms#

Your fast lookup in the room — hear the symptom, reach for the file:

8Common Mistakes That Fail Candidates#

9Worked Example: Design a URL Shortener#

A compact end-to-end run through RADIOS, to see the method in motion.

R — Requirements. Functional: shorten a long URL → short code; redirect short code → long URL; (optional) custom alias, analytics. Non-functional: extremely read-heavy (redirects ≫ creations, ~100:1); redirects must be very low latency (<100 ms) and highly available (a dead link is bad UX); creations can tolerate slightly more latency; short codes must be unique. Scope out user accounts/dashboards unless asked.

Estimation. Say 100M new URLs/day → ~1,000 write QPS (100M/10^5), and at 100:1 read:write → ~100,000 read QPS, peak ~250k. Storage: 100M/day × ~500 bytes × 5 yrs × 3 ≈ ~270 TB — needs sharding. This is a read-dominated, low-latency, high-availability problem → caching + CDN + replicas will dominate.

A — API + Data model. POST /urls {long_url} → {short_code}; GET /{short_code} → 301 redirect (301 = HTTP "Moved Permanently" — the browser follows it to the long URL and may cache the mapping forever; the alternative 302 "Found" (temporary) isn't cached by the browser, which forces every click back to your servers — worse latency and load, but it's what you must use if you want to count clicks for analytics. A classic mini trade-off to name). Entity: Url(short_code PK, long_url, created_at). Key question: how to generate unique short codes? Options: (a) hash the URL + take first 7 chars of base-62 (collision handling needed); (b) a distributed counter / ID generator (Snowflake-like, File 04) → base-62 encode → guaranteed-unique, no collision checks. Choose (b) and justify: no collision reads on the write path. 7 base-62 chars = 62^7 ≈ 3.5 trillion codes — plenty.

D — Diagram. Client → DNS → LB → stateless API servers → {Redis cache, sharded DB}. Redirect path: check Redis for short_code → long_url; hit → 301 immediately; miss → read DB, populate cache, redirect (cache-aside, File 02). Creation path: generate ID → base-62 → write to DB → return.

I — Bottlenecks. Read path at 250k QPS is the pressure point; the DB is the SPOF/bottleneck; codes must stay unique under concurrent creation.

O — Optimize.

S — Summarize. "Read-heavy, so caching + CDN + replicas carry it; unique codes via a distributed ID generator to keep the write path coordination-free; sharded, replicated storage for the 270 TB and availability. Trade-offs: I chose eventual consistency (fine for immutable links) and key-only access (so sharding is clean). With more time: analytics pipeline via Kafka, custom aliases, rate limiting on creation to stop abuse."

Notice how every decision traced to a requirement or a number, and each came with a trade-off. That's the whole game.

10Level Expectations (Junior → Staff)#

Same problem, different bar — know which you're being held to:

The higher the level, the more it's about judgment, trade-offs, and communication — and the less it's about knowing more boxes.

11Final Cheat Sheet#

 RADIOS (45 min):
   R Requirements (5)  : functional (scope DOWN) + non-functional (scale, R:W, consistency, latency, SLA)
   [Estimate (3-5)]    : QPS(/day ÷ 100k; peak = 2-3x avg) | Storage(size×count×retention×3) | BW | cache
   A API + data (5)    : core endpoints (idempotency, pagination) + entities + shard key
   D Diagram (10)      : Client->DNS->LB->stateless API->{Cache, DB} + Queue(async). Simple & correct FIRST.
   I Identify (5)      : SPOFs? what breaks at 10x? hottest path? (DB is usually first) — say them unprompted
   O Optimize (15)     : apply the bible to each bottleneck; go 2 levels deep; TRADE-OFF every choice
   S Summarize (5)     : recap, trade-offs, weak spots, "with more time…"

 EVERY DECISION = decision + benefit + COST + mitigation.  Never a component without its trade-off.
 DRIVE from requirements -> numbers -> design. Think OUT LOUD. Start simple; add complexity only when a NUMBER forces it.

 NUMBERS:  RAM 100ns | same-DC RTT 0.5ms | SSD 1MB 1ms | disk seek 10ms | cross-continent 150ms
           RAM ~100,000x faster than disk seek | seq >> random | ~100k sec/day | peak 2-3x avg
           99.9%=8.7h/yr  99.99%=52min/yr  99.999%=5min/yr

 SYMPTOM -> FILE:  traffic/HA=01 | read bottleneck=02 | abuse/tiers=03 | write/storage scale=04
   global latency/media=05 | node churn reshuffle=06 | decouple/async/spikes=07 | correctness/CAP=08
   big blobs=09 | many services/cascades/sagas=10 | which DB/index/txn=11 | method/estimation=12

 TEMPLATES: read-heavy feed (cache+CDN+fanout) | write firehose (Kafka+LSM+OLAP) | txn (ACID+idempotency+saga)
            global media (CDN+object store) | geo/proximity (geohash/quadtree)

 TOP MISTAKES: design-before-clarify | no numbers | over-engineer | no trade-offs | ignore SPOFs | go silent

One-sentence summary:

"Win the system design interview by driving a repeatable method — clarify functional + non-functional requirements, estimate the scale in numbers (QPS, storage, bandwidth, using RAM≈100ns / disk-seek≈10ms / ~100k-sec-per-day anchors), sketch a simple correct design, then proactively hunt bottlenecks and SPOFs and fix each by reaching for the right concept (cache/CDN/shard/queue/consensus…) — and above all state the trade-off of every single decision (benefit and cost and mitigation), think out loud, start simple and add complexity only when a number forces it, because they're hiring your judgment and communication, not your memory of architectures."

End of Bonus File 12. This completes the System Design Bible: 10 core concept files + 2 bonus files (Databases, Interview Playbook). You now have both the building blocks and the method to assemble them.