codequest / system design
Core concept 12 of 21

Back-of-envelope estimation

Turn users and actions into requests per second, storage and bandwidth in two minutes, the way interviewers expect.

Why estimate

Every design decision depends on scale. 100 requests per second fits on one server; 100,000 needs caching, many app servers and probably sharding. A quick estimate at the start tells you which problems are real, and interviewers expect to see it.

The method

  1. Requests per second: daily users × actions per user ÷ 86,400 (round to 100,000 seconds in a day).
  2. Peak: multiply by 2–10 depending on how spiky the traffic is.
  3. Read:write ratio: tells you whether to focus on caching (read-heavy) or write scaling.
  4. Storage: writes per day × size per write × 365 × years × copies.
  5. Servers: peak requests per second ÷ what one server handles ÷ 0.7 for headroom.

Try it

Average QPS
236.1K
reads 231.5K + writes 4.6K
Peak QPS
708.3K
× 3 peak factor
Read : write
50 : 1
read-heavy: cache it
New data / day
400 GB
before replication
Storage, 5 yr
2.2 PB
730 TB × 3 copies
App servers at peak
2.5K
400 req/s each at 70%
  1. 200M users × 102 requests ÷ 86,400 s ≈ 236.1K QPS on average
  2. Peak is 3× average ≈ 708.3K QPS, which is what you size for
  3. 400M writes/day × 1 KB ≈ 400 GB/day, so ×365 × 5 yr × 3 copies ≈ 2.2 PB

Round aggressively: interviewers want the order of magnitude and your reasoning, not the third digit. 1 day ≈ 10⁵ seconds is close enough.

Handy numbers

QuantityValue
Seconds in a day86,400 ≈ 10⁵
1 million requests per day≈ 12 per second
1 billion requests per day≈ 12,000 per second
A short text record~1 KB
A compressed photo~200 KB – 2 MB
A minute of 1080p video~50–100 MB

In the interview

  • Ask for or assume daily active users, then say your numbers out loud as you go.
  • Round hard: 10⁵ seconds in a day, powers of ten everywhere.
  • Finish with what the numbers mean: "about 7,000 QPS at peak and read-heavy, so a cache and replicas are enough; no sharding yet".