Fundamentals
Numbers to Know
Latency orders of magnitude, time conversions, and a worked storage-estimation example.
How to Prepare said to rehearse estimating orders of magnitude without a calculator. This lesson is the reference numbers worth having memorized well enough to reason from during an actual interview — not to recite, but to sanity-check your own estimates against.
Time conversions worth having automatic
- A day has ~86,400 seconds (~100,000 is close enough for a quick mental estimate).
- 1 million requests/day ≈ 12 requests/sec average — dividing daily volume by ~100,000 is the fast version of this conversion.
- Real traffic isn't flat: a 2–3x peak-to-average ratio is a reasonable default assumption unless the prompt says otherwise, and some workloads (a ticket on-sale, a live event) can spike far higher than that.
Latency numbers worth having a feel for
| Operation | Rough order of magnitude |
|---|---|
| Memory access | nanoseconds |
| SSD read | tens of microseconds |
| Same-datacenter network round trip | under 1 millisecond |
| Cross-region network round trip | tens to low hundreds of milliseconds |
| Disk seek (spinning disk) | several milliseconds |
The specific numbers matter less than the relative gaps: a cross-region round trip is roughly 100,000 times slower than a memory access. That gap is the entire reason caching and regional data placement exist as techniques — the Redis lesson's "say the eviction policy out loud" advice only matters because the memory-vs-disk-vs-network gap is this large.
Storage estimation, worked
A common estimate pattern: rows/day × average row size × retention period. For example, a service logging 10 million events/day, each ~1KB, retained for a year: 10,000,000 × 1KB × 365 ≈ 3.65TB/year. That's a single-node-sized number today, which is itself useful information — it tells you storage isn't the bottleneck for this hypothetical system, so the interview's time is better spent on whatever is the actual constraint (read latency, write throughput, availability).
Estimate only when it changes a decision
The point of a capacity estimate isn't the number itself, it's the design decision that number justifies. "3.65TB/year" is only worth computing if it answers a real question the design needs answered — does this fit on one server, does this need a cache in front of it, does this need a probabilistic structure instead of an exact one. A number with no decision hanging off it is padding, not signal, and reads that way to an interviewer: computing a precise number and then never referring back to it is a worse use of interview time than skipping the math and stating the conclusion directly ("this is small enough that storage isn't the constraint here").
The Web Crawler case study's Capacity Estimation section is the sharpest example in this track: sizing a Bloom filter at ~12.5GB for 10 billion URLs, versus ~500GB for an exact hash-set holding the same data — roughly 40x larger — is the number that justifies picking a Bloom filter over an exact set, not decoration alongside a design that was already decided. Every other case study's Capacity Estimation section is written the same way: each number exists because a specific line in the High-Level Design or Trade-offs section leans on it, not because "show your math" is a box to check.
Read:write ratios
Most consumer systems are read-heavy — often 10:1 or higher, sometimes much higher for a feed or a catalog. Naming the ratio matters because it decides where the design should spend its complexity: a design might warrant a denormalized, cache-heavy read path even at real write-path cost, exactly the trade-off the News Feed case study makes explicit. A write-heavy system — an ingestion pipeline, a metrics collector — needs the opposite instinct: partitioning and buffering writes matters more than optimizing reads that barely happen.