What is back-of-envelope estimation?
Back-of-envelope estimation is rough arithmetic that turns business numbers ("10 million orders a month") into engineering numbers ("about 4 requests per second") so you can tell whether you need one machine or a fleet — BEFORE you design anything.
The liberating rule: only the order of magnitude matters — is it closer to 10, 1,000, or 1,000,000? An answer of 4/sec versus a true 6/sec is the SAME answer (one modest server either way). An answer of 4/sec versus 4,000/sec is a completely different system. Interviewers grade the reasoning and the magnitude, never the decimal places.
- order of magnitude
- — which power of ten a number is near: ~10, ~100, ~1,000…
- QPS
- — queries (requests) per second — the standard rate unit
Words to know
Why interviews always ask for numbers
Two candidates design SliceNow. Both draw the same boxes. One says "we should probably add caching for scale." The other says: "10M orders a month is about 4 per second — a single database handles that fine. But menu READS are maybe 100× that, ~400/sec across restaurants, and spiky at lunch — THAT read path is what needs the cache."
Same diagram; completely different credibility. The numbers are what turn a drawing into an engineering decision — they tell you which problems are real (the read spike) and which are imaginary (order write volume). That is why estimation comes right after requirements in every real interview.
Orders
10M/month ≈ 4/sec
Menu reads
~100× orders ≈ 400/sec
Conclusion
cache the READ path
The 4-step method
Step 1 — start from a given. Anchor on a number you were told or asked for: "10M orders per month."
Step 2 — convert to per-second when you need a rate. The two conversions to memorize: a day is ~100,000 seconds (86,400 rounded), a month is ~2.5 million seconds. So 10M orders/month ÷ 2.5M sec ≈ 4 orders/sec. Notice the brutal rounding — that is a feature, not sloppiness.
Step 3 — for storage: items × size × time kept. Each order record ~2 KB; 10M orders/month × 12 months = 120M orders/year; 120M × 2 KB ≈ 240 GB per year. A single disk holds years of this.
Step 4 — sanity-check against reality. Under ~1,000/sec: one solid server's territory. Around 10,000/sec: a small fleet behind a load balancer. Past 100,000/sec: serious distributed territory. Your answer should land somewhere on this ladder and drive a design decision.
The numbers worth memorizing
Rounded on purpose — these are estimation numbers, not physics.
| Fact | Rounded value | Use it for |
|---|---|---|
| Seconds in a day | ~100,000 | daily volume → per-second rate |
| Seconds in a month | ~2.5 million | monthly volume → per-second rate |
| One solid server / database | ~1,000 req/sec | the "do I need to scale?" line |
| Small text record | ~1 KB | storage math for orders, users, links |
| Photo | ~1 MB (1,000× a record) | why files live in object storage, not the DB |
| Peak vs average | ×5 to ×10 | lunch rush / launch day headroom |
Quick check
A photo-sharing app gets 50 million uploads per month. Roughly what is the average upload rate?
Quick check
Your average is 20 requests/sec. What number should you actually design capacity for, and why?
Match them up
Match each quantity to the calculation that produces it.
0/4 matched — tap a term on the left.
Common trap — The precision trap
Writing "10,000,000 ÷ 2,592,000 = 3.858 req/sec" in an interview is a red flag, not rigor — it says you do not know which digits matter. Say "call it 4 a second" and move on to what the number MEANS. Brutal rounding is the professional move.
Apply it in an interview
The URL-shortener problem has a full estimation stage — givens, quantities, and instant feedback on whether your magnitude is right. Your 4-step method is all it takes.