2. Back-of-Envelope Estimation
1
The picture to keep in your head2
2.1 Why estimate at all?3
2.2 Which units and sizes should you know?4
2.3 What time shortcuts make the maths easy?5
2.4 Which latency numbers should every developer know?6
2.5 How do you turn daily users into requests per second?7
2.6 Why does the read/write ratio matter?8
2.7 Why size for the peak, not the average?9
2.8 How do you estimate storage over the years?10
2.9 How do you estimate bandwidth?11
2.10 How much memory does the cache need?12
2.11 How many servers do you need?13
2.12 How do you round, and how do you know you're not way off?14
Memory card and where the analogy breaks15
Practice: five levels16
Interview questions17
Solutions18
Sources19
Code lab2. Back-of-Envelope Estimation
2.11 How many servers do you need?
3 min read+10 XP
At the wedding: If one cook makes 50 plates an hour and the lunch rush needs 500 an hour, you need 10 cooks. But you hire more than 10: nobody works at 100% for hours, and someone always falls sick.
In the system:
servers = peak requests per second ÷ (one server's capacity × target utilisation) + spares
- One server's capacity depends entirely on the work per request. A simple cached lookup might handle thousands a second; a heavy request, far fewer. In an interview, assume a number and say it's an assumption ("say 1,000 requests a second per server"). In real life, measure it with a load test.
- Target utilisation: don't plan to run at 100%. Running around 60 to 70% leaves room for spikes and slow moments.
- Spares: at least one extra, so losing a server doesn't overload the rest.
PicShare (assumed 1,000 requests a second per server, 60% utilisation, 1 spare):
- 17,400 ÷ (1,000 × 0.6) = 29 → 29 servers + 1 spare = 30.
Why this matters more than the exact count: 30 servers is "a normal fleet behind a load balancer". 3,000 would mean rethinking the work per request first.
Memory code: "Peak ÷ per-server, leave headroom, add a spare."