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.7 Why size for the peak, not the average?
3 min read+10 XP
At the wedding: Guests don't arrive evenly from morning to night. Everyone walks in around 1 pm. A kitchen sized for the "average plates per hour" collapses at lunch.
In the system: Traffic follows people's day. It's quiet at night and spikes when people are free, and big events (a sale, a cricket final, a results day) can spike it far higher.
Figure: the average is what your daily total gives you. The peak is what your servers must survive.
- Peak factor: peak traffic ÷ average traffic.
- If you don't know it, assume 2 to 3 times the average for normal daily patterns, and say so.
- For known events (flash sales, ticket openings at a fixed time), ask the interviewer. Those peaks can be many times higher, and they're often the whole point of the question (Chapter 43, Tatkal).
PicShare: average 5,800 reads a second × 3 = about 17,400 at peak. That's the number you design servers and caches for.
Memory code: "Plan for 1 pm, not the daily average."