Back-of-the-Envelope Estimation
How many servers do you need? Guess — then prove it.
Mission
Interactive Simulation
Before we explain anything — play. Push it until it breaks, then fix it.
Show your work
Estimate first, then reveal. Interviewers care about the reasoning and round numbers, not decimals.
Workload
Your estimate: provision it
What just happened?
Daily users × actions ÷ 86,400 gave average QPS; multiplying by a peak factor told you how many servers survive the busiest minute. Writes × size × retention × replication gave storage. Too few and the system fell over; too many and the bill exploded.
The concept
Back-of-the-envelope estimation is quick, rounded arithmetic that sizes a system before you design it. The core moves: convert daily volume to per-second (÷ ~10⁵), apply a peak multiplier, divide by per-server capacity, and multiply storage by retention and replication. Know your powers of two, rough latency numbers (memory ≪ network ≪ disk), and what each extra nine of availability means in downtime.
Trade-offs
Nothing is free. Here's what this solution costs you.
In the real world
Capacity planning before launches, cloud cost forecasts, and the first five minutes of nearly every system design interview.
Mini quiz
A service gets 100M requests per day. Roughly how many per second on average?
Interview me
The app becomes your interviewer. One question, in your own words.
Boss challenge
Right-size a 150M-user service
Set daily users to 100M+ and provision servers and storage for your workload.
Goal: Provide enough servers and storage for peak and full retention — but never more than 2× what's needed.
Use the simulator above with no hints. These checks update live as you play.
Interview question
“Estimate QPS, peak QPS, storage over 5 years and bandwidth for a Twitter-like service with 150M daily users. State your assumptions.”