Foundations / Beginner / 8 min
Back-of-the-envelope capacity planning
Turn daily users into requests per second, storage, bandwidth and a server count, with every step shown.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- Back-of-the-envelope maths turns users into requests per second, storage per year and the number of machines.
- Why it matters
- The numbers decide the design: 100 requests per second fits on one server, 100,000 needs sharding, caching and queues.
- The trade-off
- Estimates are rough on purpose; round hard (1 day ≈ 100,000 s) and plan for peak traffic, not the average.
- Say it in an interview
- "10 million daily users × 10 requests ÷ 100,000 seconds is about 1,000 requests per second, about 3,000 at peak."
Check yourself
About how many seconds are in a day, for quick estimates?
Answer: 10⁵. 86,400 s rounds to 10⁵, which makes dividing daily totals by a day easy.
100 million users each make 10 reads a day. Roughly what is the average read QPS?
Answer: 12,000. 10⁹ reads ÷ ~86,400 s ≈ 11,600 per second, so about 12k. Peak would be a few times higher.
Why multiply storage by a replication factor?
Answer: Each item is stored on several machines for durability and availability. Keeping 3 copies is common, so raw storage needed is about 3× the logical data.