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.3 What time shortcuts make the maths easy?
3 min read+10 XP
At the wedding: You don't plan per minute. You think "the lunch service is about 2 hours", and work from that.
In the system: Almost every estimate divides by time, so learn a few:
| Period | Exact seconds | In your head |
|---|---|---|
| 1 day | 86,400 | ≈ 100,000 (10⁵) |
| 1 month (30 days) | 2,592,000 | ≈ 2.5 million |
| 1 year | 31,536,000 | ≈ 30 million |
And the one shortcut that does most of the work:
- 1 million per day ≈ 12 per second (exactly 11.57).
So 100 million a day is about 1,200 a second, and 1 billion a day is about 12,000 a second.
Why round 86,400 up to 100,000? Dividing by 100,000 is just knocking off five zeros. It makes your answer about 14% too low, which is fine for an estimate, as long as you remember the true answer is a bit higher.
Memory code: "A day is 100k seconds. A million a day is 12 a second."