Strong system designers reach for numbers early. You do not need exact figures — you need the right order of magnitude to answer "one server or a thousand?" This lesson gives you the handful of numbers worth memorizing and shows the arithmetic on worked examples.
Latency numbers worth memorizing
Rounded to powers of ten, cheapest to most expensive:
- L1/L2 cache reference: ~1 ns
- Main memory (RAM) reference: ~100 ns
- Read 1 MB sequentially from RAM: ~10 microseconds
- SSD random read: ~100 microseconds
- Read 1 MB from SSD: ~1 ms
- Round trip inside one data center: ~0.5 ms
- Spinning-disk (HDD) seek: ~10 ms
- Round trip across a continent / between regions: ~100–150 ms
The headline: RAM is roughly 100,000x faster than a cross-region round trip, and an SSD read is roughly 1,000x faster than that same hop. This is why caching and keeping data close to compute dominate performance work.
The "1 day ≈ 100,000 seconds" trick
A day has 86,400 seconds. Round it to 1e5 (100,000). This single trick turns "per day" into "per second" instantly:
- 1 million events/day ÷ 1e5 = ~10 events/sec
- 1 billion events/day ÷ 1e5 = ~10,000 events/sec
Memorize 1 day ≈ 1e5 s and most QPS math becomes mental arithmetic.
Powers of ten for bytes
- 1 KB = 1e3 bytes
- 1 MB = 1e6 bytes
- 1 GB = 1e9 bytes
- 1 TB = 1e12 bytes
- 1 PB = 1e15 bytes
Each step up is 1,000x. Keeping everything in scientific notation (1e6, 1e9) makes multiplication and division trivial — just add or subtract the exponents.
Deriving QPS from DAU
The chain is almost always DAU → actions/day → average QPS → peak QPS:
- Start with daily active users (DAU).
- Estimate actions per user per day for the feature.
- Multiply, then divide by 1e5 (seconds/day) to get average QPS.
- Multiply by a peak factor (traffic is spiky; 2x–10x is common) to get peak QPS.
Always size for peak, not average.
Worked example 1 — timeline reads
Assume 200M DAU, each opening their timeline 20 times/day.
- Reads/day = 200e6 × 20 = 4e9 reads/day
- Average QPS = 4e9 ÷ 1e5 = 40,000 QPS
- Peak (×3) = ~120,000 QPS
Conclusion: 120k read QPS is far past one machine — you need caching plus horizontal read replicas.
Worked example 2 — storage for posts
Assume 200M DAU, each posting 2 items/day, each item ~300 bytes (text + metadata).
- Items/day = 200e6 × 2 = 4e8 items/day
- Bytes/day = 4e8 × 300 = 1.2e11 = 120 GB/day
- Per year = 120 GB × 365 ≈ 44 TB/year (text only)
Conclusion: text is cheap; the real cost will be images and video, which pushes you toward object storage plus a CDN.
Worked example 3 — bandwidth for an image feed
Assume 1M image views/sec at peak, average image 200 KB.
- Bytes/sec = 1e6 × 200e3 = 2e11 = 200 GB/sec
Conclusion: no single origin serves 200 GB/s. That number alone justifies a CDN caching images at the edge.
In the interview
- Announce your assumptions ("200M DAU, 20 reads each") before you compute — graders reward explicit inputs.
- Keep everything in powers of ten; carry the exponents and round aggressively.
- Size for peak QPS, and let a scary number (120k QPS, 200 GB/s) justify the caching, sharding, or CDN you add next.