Back-of-the-envelope estimation
Turn vague requirements into rough numbers that justify your design choices.
Visual model
Turn a daily number into peak traffic
Why the rough math matters
Capacity estimates tell you whether you need one database or a hundred, whether a cache fits in RAM and where the bottleneck may appear.
You do not need precision. Find the right order of magnitude quickly.
Drive everything from a couple of anchor numbers (users or requests per day) and derive the rest: QPS, storage, and bandwidth.
The numbers to keep in your head
Memorize a few conversions and latencies so you can estimate in seconds.
- ~100K seconds in a day (86,400 is about 1e5): daily count divided by 1e5 is roughly average QPS. Peak is often 2-3x average.
- Powers of two: a thousand is about 2^10 (KB), a million about 2^20 (MB), a billion about 2^30 (GB), a trillion about 2^40 (TB).
- Rough latencies: memory read ~100 ns, SSD read ~100 us, network round-trip within a datacenter ~0.5 ms, cross-continent ~100+ ms.
- Always state the read-to-write ratio and hot-set size. They shape your caching and replication strategy.
A worked rhythm
Estimate average QPS from daily volume, then multiply it by a peak factor.
Estimate storage from record size, daily records and retention. Estimate bandwidth from response size and QPS.
Finally ask whether the hot set fits in one cache node and whether one database can handle the writes.
Those answers reveal the first likely bottleneck.
See it
Three formulas shape the first design
Key takeaways
- Aim for the right order of magnitude, not precision. Start with QPS, storage and bandwidth.
- Use ~1e5 seconds/day for QPS and powers of two for storage to estimate in your head.
- Read:write ratio and hot-set size are the numbers that actually drive the design.