Art of Codeartofcode
Lesson 13 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

2.12 How do you round, and how do you know you're not way off?

3 min read+10 XP

Checking yourself

At the wedding: Nobody says "we need 47.3 kilos of rice". You say "about 50", and you sanity-check it: "500 guests, 100 grams each, yes, 50 kilos."

In the system:

Round hard. Keep one or two significant figures. 5,787 → "about 6,000". 1.46 PB → "about 1.5 PB". Precision you can't justify only slows you down.

Keep the units in every step. "500 million views × 200 KB" makes it obvious the answer is in KB and needs converting. Most big estimate errors are unit errors (bits vs bytes, per day vs per month).

Sanity-check with a second route. Does the answer fit with something you know?

  • "9 Gbps out on average": that's a lot for one machine, so yes, a CDN makes sense.
  • "Only 23 writes a second": one database handles that easily, so the write path isn't the problem. The read path is.

Know which errors matter. Being off by 20% changes nothing. Being off by 10 times changes the design. Check the number of zeros, not the decimals.

Memory code: "Right zeros, not right decimals."