Back-of-the-envelope estimation
Back-of-the-envelope estimation is doing capacity math to one significant figure, 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.
- QPS (Queries Per Second)
- The number of requests a system handles each second — the unit you size capacity in.
- DAU (Daily Active Users)
- Unique users who take at least one action in a 24-hour window. The usual starting point for a traffic estimate.
The numbers to memorize
Three constants cover most estimates: 86,400 seconds per day (round to 10^5), the powers of two (2^10 ≈ 1 thousand, 2^20 ≈ 1 million, 2^30 ≈ 1 billion), and the peak multiplier (peak QPS ≈ 2 × average). With those, most capacity questions become one division.
Worked example
Say 1 million DAU each make 10 requests a day. That’s 10 million requests ÷ 10^5 seconds ≈ 100 average QPS, so ~200 QPS at peak. If each request stores 1 KB, a day is 10 GB and a year is ~3.6 TB — then add 20–30% headroom for database indexing overhead before you quote a storage number.
Where it breaks
Estimation tells you if a design is off by 10× — it will not tell you if it’s off by 20%. Use it to reject implausible designs early and to size the first deployment, not to set a production SLO.
Check yourself
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.