"How much storage for one day? For ten years?" Estimation turns a vague prompt into numbers that justify every later decision. It's a party trick you can learn in 30 minutes.
⏱ 30 minPrereq: Unit 01You'll be able to: size QPS, storage, and bandwidth in your head
By the end of this unit
Memorize the handful of numbers every estimate is built from.
Convert DAU → requests/second, and writes/day → storage/day → storage/10-years.
Use the read:write ratio to decide where to spend (caches vs write throughput).
Play with a live calculator so the arithmetic becomes muscle memory.
The numbers to memorize
Estimation is just multiplication once you anchor a few constants. Round aggressively — interviewers want orders of magnitude, not accuracy to 3 digits.
Time & traffic
1 day ≈ 86,400 s ≈ 10⁵ s (round to 100k)
QPS = daily requests ÷ 10⁵
Peak ≈ 2–3× average QPS
1 million/day ≈ ~12 QPS average
Sizes (powers of 2 ≈ powers of 10)
KB 10³ · MB 10⁶ · GB 10⁹ · TB 10¹² · PB 10¹⁵
ASCII char ≈ 1 byte · UUID ≈ 16 B
A tweet-sized row ≈ ~1 KB
A photo ≈ ~1 MB · short video ≈ 10–100 MB
Latency ladder (Jeff Dean numbers, rounded)
Memory read ≈ 100 ns · SSD random read ≈ 100 µs · network round-trip within a datacenter ≈ 500 µs · disk seek ≈ 10 ms · cross-continent round trip ≈ 100–150 ms. Translation: memory is ~1000× faster than SSD, which is ~100× faster than spinning disk. This is the whole reason caches exist.
The estimation pipeline
Two outputs from the same inputs: a throughput number (QPS → how many servers) and a storage number (bytes/day → how big a database, ×3650 for 10 years).
Worked example: a photo-sharing app
Assume 100M DAU, each user uploads 2 photos/day and reads their feed 20×/day. Photo ≈ 1.5 MB, metadata row ≈ 1 KB.
Storage/day (media): 200M × 1.5 MB = 300 TB/day. That's a lot → object store + CDN, not a database.
Storage/10 yr: 300 TB × 365 × 10 ≈ ~1 EB (exabyte). You'd discuss tiering cold data to cheaper storage.
Storage/day (metadata): 200M × 1 KB = 200 GB/day → ~700 TB over 10 yr → fits a sharded database.
The point isn't the digits It's the conclusion: read-heavy, media goes to object storage + CDN, metadata is sharded. Estimation exists to justify architecture, so always say the "therefore."
Try it — live capacity calculator
Capacity estimator
Tweak the inputs; the conclusions update live. Use it to build intuition for how one assumption swings the whole design.
—
Quick check
A service handles 500 million requests per day. Roughly what is the average QPS?
~5,000 QPS. 500M ÷ 10⁵ (seconds/day) = 5,000. Peak would be ~10–15k. Memorizing "1 day ≈ 10⁵ s" makes this instant.
Quick check
You estimate a 50:1 read:write ratio. What does that immediately suggest?
Cache + read replicas. A read-heavy ratio means most traffic can be served from memory and replicas, sparing the primary. A write-heavy ratio (e.g., logging/metrics) would instead push you toward queues, batching, and write-optimized stores like LSM-tree databases.
Practice before you move on
Estimate, on paper, for a messaging app: 500M DAU, 40 messages sent/user/day, message ≈ 300 bytes. Find (a) write QPS, (b) storage/day for messages, (c) storage for 5 years. Then state the one-sentence "therefore." Check yourself with the calculator above.