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.6 Why does the read/write ratio matter?
3 min read+10 XP
At the wedding: Each dish is cooked once but served hundreds of times. Cooking and serving are different jobs, so you staff them differently: a few cooks, many servers at the counter.
In the system: Reads (viewing) and writes (creating or changing) stress different parts of a system. Estimate both.
For PicShare (assumed): 2 million photo uploads a day.
- Writes ≈ 2 million ÷ 86,400 ≈ 23 a second.
- Reads ≈ 5,800 a second.
- Ratio = 500 million ÷ 2 million = 250 reads for every write.
What the ratio tells you:
| Shape | Examples | It points you to |
|---|---|---|
| Read-heavy | Photo feeds, product pages, URL shorteners | Caches, read replicas, CDNs: make copies |
| Write-heavy | Logs and metrics, chat messages, location updates | Queues, sharding, append-friendly storage: spread the writes |
| Balanced | Collaborative docs, some games | Both, chosen per feature |
Memory code: "Read-heavy? Copy it. Write-heavy? Spread it."