Back-of-the-envelope estimation is capacity math to one significant figure, done fast, to check whether a design is plausible. You trade precision for speed. The goal is the right order of magnitude, not an exact number.
Three constants cover most estimates. A day is 86,400 seconds, which you round to 10^5. The powers of two go 2^10 ≈ 1 thousand, 2^20 ≈ 1 million, 2^30 ≈ 1 billion. And peak QPS is about 2× average. With those, most capacity questions become one division.
Say 1 million DAU each make 10 requests a day. That’s 10 million requests ÷ 10^5 seconds ≈ 100 average QPS, so about 200 QPS at peak. If each request stores 1 KB, a day is 10 GB and a year is ~3.6 TB. Add 20–30% headroom for database indexing overhead before you quote that storage number.
Estimation tells you whether a design is off by 10×. It will not tell you whether it’s off by 20%. Use it to reject implausible designs early and to size the first deployment. Don’t use it to set a production SLO.
Source: Alex Xu, System Design Interview Vol 1, Ch. 2
Answer to reveal the explanation. Nothing is scored.
1A service receives 864,000 API calls per day. What is the average QPS?
864,000 ÷ 86,400 s = 10 average QPS. Peak is about double, ~20 QPS.
2You size capacity for average traffic. What goes wrong?
Traffic is bursty. The rule of thumb is peak QPS ≈ 2× average, so sizing for the average leaves you short at peak.
3Roughly how many bytes is 2^30?
2^30 ≈ 10^9 ≈ 1 GB. Memorize 2^10≈1K, 2^20≈1M, 2^30≈1G, 2^40≈1T.