system-design

Estimation Drills

Back-of-the-envelope estimation is a skill you can drill until it’s automatic. This chapter is a set of graded exercises — with worked solutions — that take you from “I freeze at mental math” to “I can size any system in 90 seconds and use the numbers to drive design.” Do these until the numbers come without effort.

Prerequisites: Latency Numbers, Back-of-Envelope Estimation, Estimation in Interviews Time to work through: ~30 minutes, then revisit

The numbers to memorize first

🚨 You can’t estimate without a few anchors. Burn these in:

Powers of ten (data): KB 10³ · MB 10⁶ · GB 10⁹ · TB 10¹² · PB 10¹⁵.

Time: 1 day ≈ 86,400 s (round to 10⁵) · 1 month ≈ 2.6M s · 1 year ≈ 31.5M s (~3×10⁷).

Latency (full table): | Operation | Time | | — | — | | L1 cache | ~1 ns | | Main memory | ~100 ns | | SSD random read | ~100 µs | | Network round trip (same DC) | ~0.5 ms | | Disk (HDD) seek | ~10 ms | | Network round trip (cross-continent) | ~100–150 ms |

Sizes: a char ~1 byte · a typical web page ~1 MB · a tweet ~300 bytes · a photo ~1–5 MB · a minute of 1080p video ~50 MB.

Throughput anchors: one modern server ~10K–100K QPS (simple) · a single Redis node ~100K+ ops/s · a single SQL DB ~a few K writes/s comfortably · disk sequential ~hundreds of MB/s.

The method (recap)

  1. State assumptions (users, actions/user/day) — round aggressively.
  2. Per-second = total / time. Use 10⁵ s/day. Peak ≈ 2–5× average.
  3. Storage = objects × size × retention.
  4. Bandwidth = requests/s × payload.
  5. 🚨 Draw a conclusion — “writes are trivial, reads need a cache.” Numbers you don’t use are wasted.

Drills (attempt each before opening the solution)

Drill 1 — QPS from DAU

A service has 100M daily active users, each making 20 requests/day. Average and peak QPS?

Solution 100M × 20 = 2B requests/day. Per second: 2×10⁹ / 10⁵ = **~20,000 QPS average.** Peak at ~3×: **~60,000 QPS.** Conclusion: well beyond one server → need a load-balanced fleet + caching. The method: total actions ÷ ~10⁵ seconds/day, then ×3 for peak.

Drill 2 — Storage growth

A photo service ingests 10M photos/day, average 2 MB each (across sizes). Storage after 3 years?

Solution Per day: 10M × 2 MB = 20 TB/day. Per year: 20 TB × 365 ≈ **~7.3 PB/year.** Three years: **~22 PB.** Conclusion: object storage + tiering + a CDN; this is a storage/bandwidth-dominated design, not a compute one. Method: objects/day × size = daily bytes, × 365 × years.

Drill 3 — Read/write ratio drives caching

A URL shortener does 40 writes/sec. Reads are 100× writes. What’s the read QPS, and what does it imply?

Solution Reads = 40 × 100 = **4,000 reads/sec** average, peak ~20,000. Implication: writes are trivial (a single DB handles 40/s), but 20K reads/sec at low latency 🚨 **demands a cache** in front of the DB (high hit rate, since popular links dominate). The whole design pivots on this ratio — always compute it.

Drill 4 — Bandwidth

A video service streams to 1M concurrent viewers at an average 5 Mbps. Total egress bandwidth? What does it force?

Solution 1M × 5 Mbps = 5×10⁶ Mbps = **5 Tbps.** No origin can emit terabits/sec → 🚨 **a CDN is mandatory**; the vast majority of bytes must come from edge caches. Method: concurrent streams × per-stream bitrate. This is why video design centers on the CDN.

Drill 5 — Does it fit in memory?

You want to cache 500M key→value pairs, each ~200 bytes. How much RAM? One machine or many?

Solution 500M × 200 bytes = 10¹¹ bytes = **~100 GB.** That exceeds a typical single node's usable RAM (and you want headroom + replicas), so 🚨 **shard across several cache nodes** (e.g. a few nodes of 64 GB). Method: count × size, compare to a machine's RAM (~64–256 GB). This decides single-node vs distributed.

Drill 6 — Tweets/timelines (the fan-out sniff test)

300M DAU, 2 tweets/user/day. Average user has 200 followers. What’s the daily fan-out write volume if you push every tweet to every follower’s timeline?

Solution Tweets/day: 300M × 2 = 600M. Fan-out writes: 600M × 200 followers = **1.2×10¹¹ timeline writes/day** ≈ **~1.2M writes/sec average**, peak far higher — and that's with an *average* follower count; a celebrity with 100M followers makes *one* tweet cost 100M writes. 🚨 This is exactly why pure fan-out-on-write breaks and you need the [hybrid](/system-design/12-case-studies/08-twitter.html). Method: multiply the amplification factor (followers) into the base rate.

Drill 7 — Number of servers

Your service must handle 500,000 QPS. Each server handles 5,000 QPS. How many servers (with redundancy)?

Solution 500,000 / 5,000 = **100 servers** for load, + headroom for peak and failure (N+ redundancy) → **~130–150 servers.** Method: total QPS ÷ per-server QPS, then add margin. Never size to exactly 100% — provision for peak and for losing a few nodes.

Drill 8 — Write throughput vs one database

You have 200,000 writes/sec. A single SQL primary comfortably handles ~5,000 writes/sec. What do you do?

Solution 200,000 / 5,000 = **40× over a single primary.** One DB can't take it, and writes 🚨 don't scale by read-replicas. Options: **shard** the write load across ~40+ shards, batch/async writes, or use a write-optimized store (LSM-based). Method: compare required write rate to a single node's write ceiling; if it's many×, you're sharding. This is the [scaling writes](/system-design/10-performance/03-scaling-writes.html) problem.

Drill 9 — Ingestion volume (metrics/logs)

10,000 hosts each emit 1,000 metrics every 10 seconds. Data points per second? Yearly storage at 10 bytes each (before compression)?

Solution Points/sec: (10,000 × 1,000) / 10 = **1M points/sec.** Yearly raw: 1M × 10 bytes × 3×10⁷ s ≈ **~300 TB/yr** (before time-series compression, which cuts it ~10×, and before downsampling). Conclusion: 🚨 a [time-series DB](/system-design/12-case-studies/25-metrics-system.html) with compression + downsampling. Method: (hosts × metrics) ÷ interval = rate; rate × size × seconds/year = storage.

Drill 10 — Latency budget

A request fans out to 5 services sequentially, each a 10 ms same-DB call plus one 0.5 ms network hop. Plus a 100 ms cross-continent hop to the user. Rough end-to-end latency? Where’s the fat?

Solution 5 × (10 + 0.5) = 52.5 ms internal, + 100 ms user hop ≈ **~150 ms.** 🚨 The dominant cost is the cross-continent hop (100 ms) — optimizing the internal 52 ms barely moves it; put a CDN/edge or a regional replica near the user instead. Also: those 5 sequential calls could be parallelized to ~10 ms if independent. Method: sum the path, then find the dominant term ([Amdahl](/system-design/10-performance/01-finding-bottlenecks.html)) before optimizing.

How to drill this

🚨 Speed comes from reps. Do 3–5 of these a day for a week:

🛠️ Try it

1. The 90-second app teardown. Every day, pick one app (WhatsApp, your bank, a game) and out loud estimate its daily active users, requests/sec, storage/year, and one design implication — in 90 seconds. Do it until the anchors are automatic.

2. Estimation-only mocks. Have a partner throw system names at you; you produce QPS + storage + bandwidth + one conclusion each, rapid-fire. Isolate this sub-skill from full designs.

3. Redo these ten cold in a week. Come back without the solutions and re-derive each. If a method doesn’t come instantly, that’s the one to drill more.

Further reading

This site is open source. Improve this page.