Back-of-Envelope Estimation
Back-of-envelope estimation (also “BOE estimation,” “napkin math,” “Fermi estimation”) is the senior engineer’s reflex to reach for numbers before reaching for designs. The interviewer says “design Twitter at 200M DAU” and the strong candidate immediately computes: 200M users × 5 tweets/day = 1B writes/day = ~12K writes/sec average, ~36K peak. That number determines whether you need one machine or 1,000. This note is the number card every senior engineer should have memorized — latency at every level of the memory hierarchy, throughput of common hardware, time conversions, and orders of magnitude — plus the patterns for using these numbers in System Design Interview Framework Phase 2. The numbers are due to Jeff Dean’s 2009 Stanford talk “Numbers Every Programmer Should Know”; the patterns are Jon Bentley’s Programming Pearls Ch. 7.
1. Why This Matters
Two reasons:
Numbers ground design decisions. Without them, every component choice is hand-waving. “Use Redis” is a guess; “Use Redis because we need <1ms reads at 100K QPS, which RAM can deliver but disk can’t” is engineering. Senior interviewers test specifically for this reflex — can the candidate convert “100M DAU” to “12K writes/sec” without a calculator? Can they tell whether a workload fits on one machine? The numbers are the connective tissue between requirements and design.
The numbers eliminate dead ends fast. If a system needs 1B QPS, you can stop entertaining single-machine designs in 30 seconds. If storage growth is 5 PB/year, you can stop discussing PostgreSQL primary-replica topologies. Estimation prunes the design space before you’ve drawn a single box. The interview alternative — exploring every design and discarding only when a problem surfaces — burns the clock and signals weak architectural judgment.
The Jeff Dean numbers below are dated to ~2009 hardware. Many have shifted (RAM is faster; SSDs are vastly faster; network bandwidth is higher). The orders of magnitude have not. L1 cache is still ~100× faster than RAM; RAM is still ~1,000× faster than SSD; SSD is still ~100× faster than HDD; cross-datacenter network is still ~10,000× slower than local RAM. The relative scale is what matters — interviewers care that you know “RAM ≈ 100ns; SSD ≈ 100µs; cross-continent ≈ 100ms,” not that you have the 2026 update memorized.
2. The Master Latency Table — Jeff Dean Numbers
This is the most-printed table in system-design interview prep. Memorize it. Source: Jeff Dean’s 2009 Stanford talk, with later updates by Peter Norvig and Colin Scott.
| Operation | Latency | Notes |
|---|---|---|
| L1 cache reference | ~0.5 ns | Inside the CPU; one or two clock cycles |
| Branch mispredict | ~5 ns | Pipeline flush penalty |
| L2 cache reference | ~7 ns | Larger, slightly slower on-chip cache |
| Mutex lock/unlock | ~25 ns | Uncontended; contended is much higher |
| Main memory (RAM) reference | ~100 ns | DRAM access; ~14× L2 |
| Compress 1 KB with Snappy/Zstd | ~2,000 ns = 2 µs | Modern fast compressors |
| Send 1 KB over 1 Gbps network | ~10,000 ns = 10 µs | Throughput-dominated |
| Read 4 KB randomly from SSD | ~150,000 ns = 150 µs | Modern NVMe SSDs are faster (~10–50 µs); 2009 numbers were ~150 µs |
| Read 1 MB sequentially from RAM | ~250,000 ns = 250 µs | Bandwidth-dominated |
| Round trip within a datacenter | ~500,000 ns = 500 µs | Same DC, different rack |
| Read 1 MB sequentially from SSD | ~1,000,000 ns = 1 ms | Sequential, throughput-limited |
| Disk seek (HDD) | ~10,000,000 ns = 10 ms | Mechanical platter seek; HDDs only |
| Read 1 MB sequentially from HDD | ~20,000,000 ns = 20 ms | HDD sequential read |
| Send packet CA → Netherlands → CA | ~150,000,000 ns = 150 ms | Cross-continent round trip; speed-of-light bound |
Key ratios to internalize (these matter more than the absolute numbers):
- L1 vs RAM: ~200×. Cache locality matters.
- RAM vs SSD: ~1,000×. Memory-resident systems crush disk-resident.
- SSD vs HDD: ~100×. Why HDDs are obsolete for performance-critical systems.
- Datacenter RTT vs RAM: ~5,000×. A network hop costs more than thousands of memory accesses.
- Cross-DC RTT vs intra-DC RTT: ~300×. Cross-region is expensive.
- Cross-continent RTT vs cross-DC: ~2–5× depending on geography.
2.1 What These Numbers Mean for Design
| If your latency budget is | You can afford |
|---|---|
| 1 ns | A few CPU instructions; no cache miss |
| 100 ns | A handful of RAM accesses (one cache miss) |
| 1 µs | Memory-resident lookup; in-process work |
| 10 µs | Same-rack network call; SSD random read |
| 1 ms | Sequential SSD read; same-DC round trip + work |
| 10 ms | Single HDD seek; cross-DC round trip; complex DB query |
| 100 ms | Cross-continent round trip; full page render |
| 1 s | Multiple network hops; offline batch boundary |
When the NFR says “redirect in <50ms p99,” you can immediately conclude: we can afford one same-DC round trip plus a cache lookup, but we cannot afford to cross continents and we cannot afford an HDD seek. The number card translates SLA into architecture.
2.2 Updated Numbers (2024–2026 era)
The Dean numbers were assembled around 2001 by Peter Norvig and popularized through Jeff Dean’s Stanford talk in the 2009–2010 window (per Colin Scott’s reconstruction, which traces every figure back to its underlying primary measurement). They are conservative for modern hardware in absolute terms; the order-of-magnitude relationships still hold, which is why they survive as the interview reference. Verified updates, with caveats:
- NVMe SSD 4 KB random read: ~10–20 µs for current enterprise NVMe at low queue depth (Simplyblock); consumer drives are wider, ~20–70 µs. Datacenter parts like the Micron 7450 publish “consistent low latency” specs in this band (Micron). This is roughly 10× faster than Dean’s 2009 figure of ~150 µs.
- DDR5 RAM access: ~10 ns of true latency in nanoseconds — e.g. DDR5-6000 CL30 ≈ 10 ns, vs DDR4-3200 CL16 ≈ 10 ns (Corsair). Counterintuitively, DDR5 did not substantially cut access latency; it bought bandwidth and parallelism. The Dean 100 ns figure includes more than CAS — it folds in row-activation, channel queuing, and (often) NUMA hops — so 80–100 ns is still a reasonable end-to-end RAM-access estimate.
- 10 GbE 1 KB send: ~1 µs vs ~10 µs on 1 GbE (linear scaling with bandwidth at the throughput-dominated end of the 1 KB transfer).
- Same-DC RTT: unchanged at ~100–500 µs. Speed of light is unchanged; intra-DC fabric is overwhelmingly dominated by switch hops and queuing, which have improved only modestly.
- Cross-continent RTT: ~50–150 ms. Anycast and better peering shave some, but transoceanic fiber speed (≈ ⅔ c in glass) is the floor.
For interview purposes, use the 2009 numbers unless asked specifically. They’re more widely recognized and the order-of-magnitude argument is the same — the interview is testing whether the candidate can reason that “RAM ≈ ns; SSD ≈ µs; disk seek ≈ ms; cross-continent ≈ 100 ms,” not whether they have a 2026 datasheet memorized. If pressed on a specific number for current hardware, give a range (“10–20 µs for an enterprise NVMe”) and name the dependence on queue depth, IO size, and queue/firmware contention — committing to a single figure without the qualifications is the failure mode.
3. Throughput Numbers
Latency is “how long for one operation”; throughput is “how many per second.” Both matter in design, often as separate constraints (a system can have great latency and terrible throughput, or vice versa).
| Resource | Bandwidth / Throughput |
|---|---|
| Modern CPU core (single-thread instructions) | ~10⁹ instructions/sec (1 GHz minimum; modern is 3–5 GHz with multi-issue) |
| Memory bandwidth (DDR4-3200) | ~25 GB/sec per channel; multi-channel systems hit 100+ GB/sec |
| Memory bandwidth (DDR5) | ~50 GB/sec per channel |
| PCIe 4.0 x16 | ~32 GB/sec |
| NVMe SSD sequential read | 3–7 GB/sec (PCIe 4.0); cap of bus bandwidth |
| NVMe SSD random 4KB read IOPS | 500K – 1M IOPS |
| SATA SSD sequential read | ~500 MB/sec (saturates SATA III) |
| HDD sequential read | 100–250 MB/sec |
| HDD random IOPS | 100–200 IOPS (limited by mechanical seek) |
| 1 Gbps NIC | ~125 MB/sec (gigabit ethernet) |
| 10 Gbps NIC | ~1.25 GB/sec |
| 25 Gbps NIC | ~3.1 GB/sec (common in modern datacenters) |
| 100 Gbps NIC | ~12.5 GB/sec (high-end) |
| 400 Gbps NIC | ~50 GB/sec (cutting-edge in 2024+) |
Implications for interview answers:
- A single SSD can drive 1M IOPS. Most workloads bottleneck on the application before they bottleneck on the disk. If your design is doing <10K IOPS to a single SSD, disk is not your problem.
- A 10 GbE link can saturate at 1.25 GB/sec. If your service is shipping more than that, it needs multiple NICs or sharding.
- HDD random IOPS is the worst common bottleneck: ~150 IOPS means a single HDD can’t handle a write-heavy workload past ~150 transactions/sec without batching. This is why LSM Tree-based stores (which convert random writes to sequential) revolutionized write-heavy workloads.
4. Time Conversions and Common Scales
The single most useful mental conversion in BOE estimation:
1 day ≈ 10⁵ seconds (precisely: 86,400 seconds)
1 year ≈ 3 × 10⁷ seconds (precisely: 31,557,600 seconds)
1 month ≈ 2.6 × 10⁶ seconds (precisely: 2,592,000 for a 30-day month)
These let you flip between “X events/year” and “Y events/sec” in your head:
- 1 event/sec → 86,400/day → 31.5M/year (≈ 30M/year for round numbers)
- 1 M events/day → ~12 events/sec average
- 100 M events/day → ~1,200 events/sec average; ~3,600 peak
- 1 B events/day → ~12,000 events/sec average; ~36,000 peak
4.1 Powers of Ten — Engineering Prefixes
| Prefix | Value | Bytes example | QPS example |
|---|---|---|---|
| K (kilo) | 10³ = 1,000 | 1 KB ≈ short paragraph of text | 1 KQPS = small service |
| M (mega) | 10⁶ = 1,000,000 | 1 MB ≈ a small image; one-page PDF | 1 MQPS = midsize service |
| G (giga) | 10⁹ = 1,000,000,000 | 1 GB ≈ a movie file; midsize DB | 1 GQPS = web-scale service |
| T (tera) | 10¹² | 1 TB ≈ small DB cluster | rare; planet-scale |
| P (peta) | 10¹⁵ | 1 PB ≈ Internet Archive total | unheard-of for QPS |
| E (exa) | 10¹⁸ | 1 EB ≈ all data on Earth (rough) | n/a |
Caveat — base 2 vs base 10: in storage contexts, 1 KB historically meant 1024 bytes (KiB), then later 1000 (KB) under SI conventions. In networking, 1 Kbps is always 1000 bits/sec. For BOE estimation, assume base 10 — the difference is <10% and within rounding.
4.2 Common QPS Anchors
Memorize these as reference points to compare against in interviews:
| QPS | Real-world reference |
|---|---|
| 1 / sec | A daily cron job’s check-in rate |
| 100 / sec | A small startup’s API |
| 1,000 / sec | Midsize SaaS API; 100M actions/day |
| 10,000 / sec | Large web service; 1B actions/day |
| 100,000 / sec | Twitter writes (~5–10K writes/sec actual; reads are much higher) |
| 1,000,000 / sec | Google searches; Facebook reads |
| 10,000,000 / sec | DNS resolution at the root; CDN edge totals |
| 100,000,000+ / sec | Aggregate of all servers at a hyperscaler |
Anchor in interviews: if your design is computing 100K QPS, ask: “this is roughly Twitter-scale on the write side; that suggests a sharded, fanout-heavy architecture.” Comparing to known systems calibrates the answer.
5. Storage Numbers
Knowing the size of common data lets you skip the data-collection step in estimation.
| Item | Approximate size |
|---|---|
| Single Unicode character (UTF-8) | 1–4 bytes (ASCII = 1 byte) |
| Tweet text (280 chars) | ~300 bytes (with metadata: ~1 KB) |
| HTTP request headers (typical) | 500–2,000 bytes |
| JSON record (small) | 200–1,000 bytes |
| JSON record (medium) | 1–10 KB |
| Compressed JSON (Gzip ratio ~5×) | divide by 5 |
| Image — thumbnail (50KB) | 50 KB |
| Image — typical web (300KB) | 300 KB |
| Image — high-res photo (3MB) | 3 MB |
| Audio — 1 minute MP3 128kbps | ~1 MB |
| Video — 1 minute SD H.264 | ~10 MB |
| Video — 1 minute HD H.264 | ~50 MB |
| Video — 1 minute 4K | ~250 MB |
| Database row (SQL, with indexes) | 100–1,000 bytes typical |
| Memcached entry | ~100–500 bytes typical (key + value + overhead) |
| B-tree page | 4–16 KB (matches OS page size) |
| Kafka message | typically <1 KB |
Scaling up: for storage projections, the formula is
storage_per_year = bytes_per_record × records_per_day × 365
Plus indexes (typically ~30–50% overhead for primary + a couple secondary indexes), plus replication factor (usually 3× for critical data). So the effective storage cost is:
effective_storage = bytes_per_record × records_per_day × 365 × index_overhead × replication_factor
For a system writing 1 KB rows at 1,000 records/sec:
- Raw: 1 KB × 1,000 × 86,400 = 86 GB/day = ~31 TB/year
- With 1.5× index overhead: ~47 TB/year
- With 3× replication: ~141 TB/year
- Five-year horizon: ~700 TB
This is a big number — it tells you immediately that you can’t run on a single host and need cold-data archival.
6. Estimation Patterns for Interviews
6.1 The Read-Heavy vs Write-Heavy Pattern
The first question after estimating QPS: which dominates, reads or writes?
| Workload | Read:Write ratio | Implications |
|---|---|---|
| Twitter / news feed | ~100:1 | Cache aggressively; precompute timelines; use Consistent Hashing for cache sharding |
| YouTube / streaming | ~1000:1 | CDN dominates; origin is rarely hit; Inverted Index for search |
| Search engine (Google) | ~1:0 (essentially read-only at query time) | Index is precomputed; query path is read-only |
| Banking / payments | ~1:1 | ACID, strong consistency, careful sharding |
| IoT / telemetry | ~1:100 (writes dominate) | Write-optimized stores (LSM Tree); time-series DBs |
| Logging / analytics | ~1:1000 (writes dominate, reads only at query time) | Append-only logs; columnar storage for read |
| Chat (messaging) | ~10:1 reads (a message is read by recipients but written once) | Fanout on write or read trade-off |
| Online ads bidding | ~1:1 with extreme latency requirements | RAM-resident; specialized infra |
The pattern: a 100:1 read-heavy workload needs a cache, replicas, or precomputation. A 100:1 write-heavy workload needs an LSM Tree or a sharded append-only log.
6.2 The Peak-vs-Average Pattern
Don’t design for average; design for peak. The standard rule of thumb:
Peak QPS ≈ 3× average QPS for diurnal workloads.
Why 3×? Most consumer products peak at evening hours (a 3–4× concentration vs the 24-hour average). Some workloads spike higher (10× for sports events, breaking news, holiday shopping — these need explicit spike capacity planning). Some are flatter (B2B systems, monitoring) — closer to 2× peak.
For interview answers: state “average is X; peak is roughly 3× average so Y” reflexively. If the interviewer pushes (“what if there’s a viral event?”), discuss spike capacity — over-provisioning, autoscaling, or graceful degradation.
6.3 The Ratio of Reads to Database Hits
A subtle but interview-rewarding observation: the cache hit rate changes the load profile dramatically.
If 99% of reads hit the cache:
- Database read QPS = 1% × total read QPS
- A 1M QPS system becomes 10K QPS to the DB — manageable on a single primary
If 50% of reads hit the cache:
- Database read QPS = 50% × total read QPS
- A 1M QPS system becomes 500K QPS to the DB — needs read replicas and probably sharding
The cache hit rate is the single most important parameter in read-heavy designs. State it explicitly and justify it (“URL access is heavily skewed — Pareto distribution; the top 1% of URLs get 99% of traffic, so a small cache covers them”). See Least Recently Used Cache and Adaptive Replacement Cache for the eviction-policy axis.
6.4 The Per-User Multiplier Pattern
For social-graph systems, the storage and compute per user multiplies by the average degree of the graph:
- 200M users × 200 friends average = 40B follow-edges
- Per-edge size ~24 bytes (two int64 IDs + metadata) = ~1 TB just for the follow graph
- Per-edge replication 3× = ~3 TB
Then storage scales linearly with users and with degree. A network with average degree 1,000 (like LinkedIn’s professional network) needs 5× the edge storage of one with average degree 200.
For timeline fanout: a tweet is written once but copied to F follower timelines (where F = follower count). For a power-user with 10M followers, a single tweet costs 10M cache writes — at scale that’s the bottleneck. This is why Twitter does fanout-on-read for celebrities (see System Design Interview Framework §4.5 for the full discussion).
6.5 The Bandwidth Sanity-Check
Always check that your design doesn’t exceed available bandwidth:
read_bandwidth = bytes_per_read × read_QPS
write_bandwidth = bytes_per_write × write_QPS
For a YouTube-style streaming service:
- 1 hour of HD video ≈ 3 GB
- 1B hours/day × 3 GB = 3 EB/day = ~35 GB/sec average egress
- Peak ~3× = ~100 GB/sec
- That’s ~1 Tbps — beyond any single datacenter’s egress; requires a CDN
For a Twitter-style read service:
- 1 KB per tweet × 100M reads/sec = 100 GB/sec
- Equivalent to ~800 Gbps — needs many machines + caching
The bandwidth sanity-check often surfaces the “you must have a CDN” or “you must shard” conclusion that would otherwise come 10 minutes later.
7. Worked Examples — Estimation in Action
7.1 “Design Twitter at 200M DAU”
- DAU: 200M
- Tweets per user per day: ~5 (rough Twitter average)
- Writes/day: 200M × 5 = 1B
- Average write QPS: 1B / 86,400 ≈ 12K
- Peak write QPS: ~36K (3× peak)
- Read:write ratio: ~100:1
- Average read QPS: ~1.2M
- Peak read QPS: ~3.6M
- Bytes per tweet (with metadata): ~1 KB
- Storage growth: 1 KB × 1B/day = 1 TB/day = ~365 TB/year
- Five-year storage: ~1.8 PB before replication; ~5.5 PB with 3× replication
Conclusions from these numbers:
- 36K write QPS is past single-machine RDBMS; need sharding.
- 3.6M read QPS is way past anything but a CDN/cache hierarchy.
- 1 PB is past any single host; need distributed storage.
7.2 “Design YouTube”
- Users: 2B
- Hours watched per user per day: ~1
- Total hours/day: 2B × 1 = 2B hours
- Total seconds/day: 7.2 × 10¹² seconds
- Bandwidth at 1 Mbps average bitrate: 7.2 × 10¹² seconds × 1 Mbps = 7.2 × 10¹⁸ bits/day = ~900 PB/day
- Average egress: ~10 TB/sec (= ~80 Tbps — well past any single org’s network)
Conclusion: the only answer is a global CDN. No clever architecture can substitute for distributed bandwidth at this scale. This is why YouTube built one of the largest CDNs in existence (Google’s Edge Network).
7.3 “How Many Servers for a 100K-QPS Service?”
If each server can handle 1K QPS sustainably (a reasonable estimate for a modest Java/Python service): 100 servers minimum, plus 50% headroom for peaks → 150 servers, plus 30% spare for failures → ~200 servers.
If each server can handle 10K QPS (Go service with cache): 10 minimum → 15 with peak → 20 with failure tolerance.
The point: the per-server QPS estimate determines the cluster size linearly, so being off by 10× on per-server QPS is a 10× cost difference. Calibrate against real benchmarks if available.
7.4 “How Long to Hash 1 GB of Data?”
- SHA-256 throughput: ~500 MB/sec on a modern x86 core (Intel SHA-NI extensions: ~2 GB/sec).
- 1 GB / 500 MB/sec = 2 seconds.
If the interviewer says “we need to hash 1 GB during a request,” you can immediately note: “hashing alone is 2 seconds — that’s way past any reasonable SLA. We’d need to precompute, parallelize, or use a faster hash like xxHash (~10 GB/sec).“
7.5 “How Long to Sort 1 TB of Data?”
- In-memory sort: if 1 TB fits in RAM (modern hyperscalers’ biggest VMs do reach 24 TB RAM), an O(n log n) sort at ~100 ns per comparison: 10¹² × log₂(10¹²) × 100ns ≈ 10¹² × 40 × 10⁻⁷ s = 4 × 10⁶ s ≈ 50 days. Too slow.
- External sort with disk I/O: read each record from disk, sort, write back. Bandwidth-bound. SSD at 5 GB/sec → 1TB / 5 GB/sec = 200 sec for the read pass. Multi-pass external sort: ~3 passes typical → 600+ seconds = 10+ minutes.
- MapReduce / Spark cluster: parallelize across 100 machines → ~10 seconds for the same workload (network-bound, not compute-bound).
The TeraSort benchmark has been the canonical “how fast can we sort 1 TB” benchmark for years; modern records sort 100 TB in under 100 seconds on hundreds of machines (Apache Spark, Tencent’s record). The point for interviews: “1 TB sort is infeasible on one machine in real time; needs distribution.”
8. Decision Framework — When the Numbers Drive the Design
flowchart TD Q1{"Compute QPS<br/>(reads + writes)"} Q1 --> Q2{"< 100 QPS?"} Q2 -->|"yes"| Single["Single machine sufficient<br/>(monolith + RDBMS)"] Q2 -->|"no"| Q3{"< 10K QPS?"} Q3 -->|"yes"| LBPool["Load balancer + 3-10 stateless servers<br/>+ replicated DB"] Q3 -->|"no"| Q4{"< 100K QPS?"} Q4 -->|"yes"| Cache["Add caching layer<br/>+ read replicas<br/>+ async write path"] Q4 -->|"no"| Q5{"< 1M QPS?"} Q5 -->|"yes"| Shard["Shard data tier<br/>(by primary key)<br/>+ multi-region"] Q5 -->|"no"| CDN["CDN-first design<br/>+ regional clusters<br/>+ bespoke infra"]
What this diagram shows. The QPS number alone often picks the entire architectural shape. Below 100 QPS, no distribution is needed. From 100 to 10K, horizontal scaling of stateless servers is enough. Past 10K, caching becomes essential. Past 100K, sharding becomes essential. Past 1M, CDN-first design dominates. A senior candidate should be able to place a system on this ladder within 60 seconds of getting the scale numbers. The ladder is approximate — specific workloads may move up or down a step (write-heavy at lower QPS may need sharding earlier; read-heavy at higher QPS may avoid sharding via deep caching) — but it’s the right first cut every time.
9. Common Failure Modes
9.1 Refusing to Estimate
Symptom: candidate says “I’d need to know the actual numbers.” Why it fails: the interviewer is testing your ability to reason from rough numbers, not your ability to look up exact data. Refusing signals risk-aversion or unfamiliarity.
Fix: always commit to numbers. If you don’t know, propose a plausible figure and confirm: “Let’s say 100M DAU — does that sound right?” The interviewer will adjust.
9.2 Estimating in the Wrong Units
Symptom: candidate computes everything in bytes when the design is dominated by network round-trips, or vice versa. Why it fails: optimizing the wrong dimension.
Fix: identify the binding constraint (latency, throughput, storage, bandwidth) and estimate in that unit. A real-time chat system is latency-bound; a video archive is storage-bound; a streaming platform is bandwidth-bound.
9.3 Forgetting Replication and Index Overhead
Symptom: candidate computes 1 TB of data and concludes “single host.” Why it fails: 1 TB raw becomes 4–5 TB after indexes and replication. The host can’t fit it.
Fix: multiply by ~3–5× at the end of any storage estimate — replication factor (typically 3) plus indexes (typically 1.3–1.5×). The “ground truth” storage is much larger than the raw data size.
9.4 Confusing Bandwidth and IOPS
Symptom: candidate computes “we need 1 GB/sec; an SSD handles 5 GB/sec, so one disk is fine.” Why it fails: 1 GB/sec at 4 KB per IO is 250K IOPS, which can saturate IOPS even when bandwidth has headroom.
Fix: check both. If random-IO-heavy, IOPS is the binding constraint. If sequential-IO-heavy, bandwidth is. Most real workloads are mixed.
9.5 Using Average When Peak Matters
Symptom: capacity planning at average QPS without headroom for peaks. Why it fails: production goes down at the first peak.
Fix: always use peak QPS (3× average rule of thumb), then add headroom for failures and spikes (typically 50% extra capacity beyond peak).
9.6 Ignoring Latency Variance
Symptom: candidate says “p50 latency is 10ms, so 100ms SLA is fine.” Why it fails: p99 (or p999) is what users notice; the tail dominates user experience. p99 is often 5-10× p50 in real systems.
Fix: state your latency target as p99 or p999, and reason about tail latency explicitly. “If p50 is 10ms, p99 is probably 50-100ms; we need to plan for the tail not exceeding the SLA.”
9.7 Memorizing Numbers Without Understanding Ratios
Symptom: candidate recites “RAM is 100 ns” but doesn’t know what that implies. Why it fails: numbers without intuition produce wooden answers.
Fix: practice the ratios (RAM is 1000× SSD; SSD is 100× HDD; cross-DC is 5000× RAM access), and apply them. The ratios let you derive the absolute numbers when memory fails.
10. Sample Phrases / Scripts
Estimation openers:
- “Let me size this. Assuming X DAU and Y actions per user per day…”
- “I’ll work in orders of magnitude — 10⁵ seconds in a day.”
- “Average is N; peak is roughly 3× average.”
- “Storage growth: bytes-per-record × records-per-day × replication-factor.”
When you don’t know a number:
- “I don’t have an exact figure for X, but it’s roughly $RANGE — let’s use the higher end to be safe.”
- “Reasonable assumption: a tweet is ~300 bytes of text plus ~700 bytes of metadata, so ~1 KB total.”
- “If you have a more accurate number, use that — but for now I’ll proceed with this estimate.”
Connecting numbers to design:
- “These numbers tell me the bottleneck is going to be X, because Y.”
- “At this scale, single-machine designs are off the table.”
- “The read-heavy ratio is what justifies the cache layer.”
- “The write QPS is past single-machine RDBMS territory; we need to shard.”
Defending an estimate:
- “I rounded up because I’d rather over-provision than under.”
- “I used the 3× peak rule; if the workload is spikier (e.g., a sports app during a match), we’d plan for 10× peak.”
- “Index and replication overhead doubled my raw storage estimate.”
11. Open Questions
- How much do the 2009 numbers under-estimate modern hardware in absolute terms? NVMe is ~10× faster; DDR5 is ~25% faster; networks are 25× faster (10 Gbps → 400 Gbps in some DCs). The orders-of-magnitude story holds, but the absolute numbers in interview answers may be conservative.
- When does “interviewer-acceptable” estimation accuracy break down? Anecdotally, ±2× is fine; ±10× starts to look like the candidate isn’t familiar with the domain.
- Which numbers are over-emphasized in prep? Many candidates over-memorize the latency table without practicing the patterns — peak-vs-average, read-vs-write ratio, cache hit rate impact. Patterns beat memorization.
12. See Also
- System Design Interview Framework — Phase 2 is where these numbers go
- Scaling Patterns — what to do once the numbers force you off single-machine
- Edge Cases Checklist — also checked during deep-dives
- Debugging Under Pressure — what to do when your numbers don’t add up
- STAR Framework — behavioral analog
- CAR Framework — behavioral analog
- Picking Stories — Coverage Matrix — selecting behavioral examples
- Problem Decomposition in Interviews — sibling skill
- Talking Through Code — narration during coding
- Time Management in Interviews — clock discipline
- FAANG Interview Loops — where this skill is graded
- Levels and Calibration — per-level signal
- How to Practice — Spaced Repetition for Algorithms — how to drill the numbers
- Negotiating Offers — what comes after passing
- Resume for SWE Roles — getting to the loop
- Consistent Hashing — sharding building block
- Least Recently Used Cache — caching primitive
- Adaptive Replacement Cache — better caching policy
- Bloom Filter — low-storage probabilistic primitive
- LSM Tree — write-optimized storage
- Inverted Index — search primitive
- Token Bucket — rate-limit primitive
- Sliding Window Rate Limiter — rate-limit primitive
- CAP theorem — consistency vs availability framing
- Big-O Notation — for the algorithmic complexity vocabulary
- Space Complexity — for analyzing data structures
- SWE Interview Preparation MOC