Part of my notebook. Terse by design. Pairs with the system design field guide.
The numbers to hold in your head
Million = 10^6 2^20 ≈ 1 million
Billion = 10^9 2^30 ≈ 1 billion
Trillion = 10^12 2^40 ≈ 1 trillion
1 KB = 10^3 B 1 MB = 10^6 B 1 GB = 10^9 B
1 TB = 10^12 B 1 PB = 10^15 B
1 min = 60 s 1 hour = 3,600 s
1 day = 86,400 s ≈ 10^5 s ← the workhorse approximation
Handy anchors: 1M x 1KB = 1GB. 1B x 1B = 1GB. 1B messages x 1KB = 1TB.
The generic formulas
- Total events/day = users x events per user
- Base rate = total events / 86,400 s (call it 10^5)
- Peak rate = base rate x peak multiplier (5x if you know it’s spiky, else assume ~10% of daily traffic lands in the peak hour)
- Daily storage = events x size per event
- Daily bandwidth out = events x response payload; in = events x upload size
Worked example: QPS
“150M DAU, 0.5 tweets per user per day, 2x at peak”:
150M x 0.5 x 2 / 10^5
= 1.5 x 10^8 x 0.5 x 2 / 10^5
= 1.5 x 10^3
= 1,500 QPS
“10B messages/day”: 10^10 / 10^5 = 100K QPS base; at 5x peak, half a million. The trick in both: reduce everything to powers of ten early, do one small multiplication at the end.
Worked example: storage
“150M users, 10% attach a photo of 100 KB, keep 5 years, 3 replicas”:
1.5 x 10^8 x 0.1 x 10^5 B x (~400 days x 5) x 3
≈ 9 x 10^15 B = 9 PB
Video variant: assume 1% attach a 100 MB video (1000x the size, 1/10 the rate) → ~100x the photo storage ≈ 900 PB. Notice you never needed a calculator, just exponent bookkeeping.
Worked example: short URLs
- Base62 (
0-9a-zA-Z); Base64 adds+and/. - 6 characters: 62^6 ≈ 3.5 trillion codes, more than enough.
- Sizing the store: 10K requests/minute for 10 years = 10^4 x 60 x 24 x 365 x 10 ≈ 8.5 billion entries. Round aggressively as you go; precision here is cosplay.
Availability nines
| Nines | Downtime per day |
|---|---|
| 99.9% | 1.44 min |
| 99.99% | 8.6 s |
| 99.999% | 864 ms |
Miscellaneous anchors
- A Linux box has ~65K ports; budget ~5K for internal use and you still hold ~60K client connections per machine.
- IPv4 addresses are 32-bit; IPv6, 128-bit.
- Geohash cell sizes: geohash-5 ≈ 5 km x 5 km, geohash-6 ≈ 1.2 km x 0.6 km. (For proximity search: query the cell plus its 8 neighbors; cells sharing a prefix are adjacent.)
- The full latency ladder lives in caching & performance.
Running a 45-minute design discussion
The template I’ve refined over the years. Timeboxes matter more than the content of any single box.
1. Feature expectations (5 min). Use cases, explicit non-goals, who uses it, how many, usage patterns. Ask what the interviewer or stakeholder actually wants to focus on before diving; define a success criterion (for a feed: time-in-app; for checkout: conversion).
2. Estimations (5 min). Read/write QPS, read:write ratio, latency targets, storage, memory for the cache tier (what’s cached, how much RAM, how many machines). Everything above feeds this.
3. Design goals (5 min). Latency and throughput commitments; the consistency vs availability call, per operation, not globally.
4. High-level design (5-10 min). APIs for the crucial read and write paths, database schema, the basic algorithm, one diagram covering both paths.
5. Deep dive (15-20 min). Scale each component with an availability, consistency, and growth story. The checklist to walk mentally: DNS, CDN (push vs pull), load balancers (L4/L7, active-active vs active-passive), reverse proxies, app-layer scaling (microservices, service discovery), databases (RDBMS: replication/federation/sharding/denormalization/tuning; NoSQL: KV, wide-column, graph, document), caches (client → CDN → web → app → database; cache-aside, write-through, write-around, write-behind, refresh-ahead), async (message queues, task queues, back pressure), communication (TCP/UDP, REST/RPC).
6. Justify (5 min). Throughput of each layer, latency between layers, overall latency budget. If the numbers from step 2 don’t survive step 5, say so and fix the design out loud; that correction is the signal.
Plus a closing beat nobody budgets for: metrics and alerts, backups and maintenance windows, security. One sentence each beats zero.