Part 0 · 2 chapters · ~12 min

The Method

The six rounds (brief, questions, numbers, v1, the break, v2 and the sentence), back-of-envelope estimation with the latency and capacity numbers worth memorising, drawing APIs and data models, and how a design round is scored.

1

Six rounds, out loud

what reviewers scorewhat it looks like
requirementsyou asked about scale, consistency and failure before drawing
estimationnumbers that drive choices, stated with units and assumptions
a working v1API, data model and flow that actually meet the brief
depthone or two components explained to the level of indexes, partitions or protocols
trade-offsevery change paired with its cost; alternatives named and rejected for reasons
failure thinkingwhat happens when each box fails, especially for money
THE ROUNDS
the same six steps for every design, out loud
1. the briefrestate it in one sentence2. questionsusers, scale, consistency, latency, failure3. numbersQPS, storage, bandwidth, memory4. v1the simplest design that meets the brief5. the breakwhat fails first at the numbers6. v2 and the sentence"v2 buys X and pays Y"
swipe the figure sideways, or tap expand for full screen
1/6
the brief
Restate the problem in one sentence and confirm it. Interviewers and stakeholders often hide the real requirement in what they did not say.
restate and confirmsurface the hidden requirement
2

Back-of-envelope estimation

code
useful conversions
1 day ≈ 86,400 s ≈ 10^5 s        1M requests/day ≈ 12 req/s average     peak ≈ 2-5 × average
1 KB × 1M/day ≈ 1 GB/day ≈ 365 GB/year
a single Postgres primary: thousands to tens of thousands of simple writes/s, far more cached reads/s
a Redis node: ~100k+ simple ops/s
a Kafka partition: tens of MB/s

example: 50M users, 20% daily active, 10 actions each, 2 KB per action stored
  writes   = 50M × 0.2 × 10 / 86,400 ≈ 1,160/s average, ~5,000/s peak
  storage  = 100M actions/day × 2 KB ≈ 200 GB/day ≈ 73 TB/year   → partitioning and archival from day one
NUMBERS WORTH KNOWING BY HEART
rough latencies that drive design decisions (orders of magnitude)
L1 cache reference~1 nsmain memory reference~100 nsSSD random read~16 µsround trip same zone~0.5 msdisk seek (HDD)~2-10 msround trip Lagos to London~80 msround trip Lagos to US East~150 ms
swipe the figure sideways, or tap expand for full screen
1/4
memory
Memory is about a hundred times slower than L1, and still about a hundred times faster than an SSD read. Caches exist because of this gap (Computers course measured 0.75 ns sequential vs 6.5 ns random per element).
memory vs cache: ~100×the Computers course measured these