Art of Codeartofcode
Lesson 9 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.8 How do you estimate storage over the years?

3 min read+10 XP

At the wedding: For a three-day wedding, you stock rice for all three days, plus a bit extra in case a sack spoils.

In the system: Storage grows every day and rarely shrinks. The formula:

storage = writes per day × size of each write × days × years × copies

PicShare (assumed): 2 million uploads a day, 2 MB each, kept for 1 year, stored 3 times for safety (replicas, Chapter 14).

  • Per day: 2 million × 2 MB = 4 TB.
  • Per year: 4 TB × 365 = 1.46 PB.
  • With 3 copies: about 4.4 PB a year.

Now the metadata (photo ID, owner, caption, time): about 1 KB per photo.

  • Per day: 2 million × 1 KB = 2 GB. Tiny next to 4 TB.

That gap is a design decision in itself: the photos go in object storage (Chapter 11), built for huge files, while the metadata goes in a database, built for fast lookups. Same app, two very different storage problems.

Memory code: "Writes × size × days × copies." And always split the small stuff (metadata) from the big stuff (media).