Art of Codeartofcode
Lesson 18 of 19

2. Back-of-Envelope Estimation

1
The picture to keep in your head
2
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 breaks
15
Practice: five levels
16
Interview questions
17
Solutions
18
Sources
19
Code lab
2. Back-of-Envelope Estimation

Sources

3 min read+10 XP

Source notes

  • Latency figures (memory ~100 ns, SSD random read ~150 µs, data-centre round trip ~500 µs, disk seek ~10 ms, California-Netherlands round trip ~150 ms): "Latency numbers every programmer should know", attributed to Jeff Dean and Peter Norvig. Approximate; they vary by hardware and year, but the gaps between them are what matter.
  • Powers of 2 (2¹⁰ = 1,024 ... 2⁵⁰ = 1,125,899,906,842,624) and all chapter arithmetic: computed 2026-10-05.
  • The 80/20 split and peak factors of 2 to 3 are common rules of thumb for interviews, not measured figures for any system.
  • PicShare, the video app and the chat app are made-up examples. All their numbers are interview assumptions, not real figures for any company.
  • Level 3 and Level 4 code: tested 2026-10-05 (code/ch02_estimator.py, all checks pass).