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.1 Why estimate at all?
3 min read+10 XP
The toolkit
At the wedding: The guest count decides what kind of kitchen you need, not just how big. Fifty guests: a home stove. Five thousand: hired caterers, big vessels, a separate serving team. The number changes the shape of the plan, not only its size.
In the system: Estimates do the same job. They tell you which design you need:
- 40 writes a second fits easily on one database. 40,000 may not, and you start thinking about sharding (Chapter 15).
- 100 GB of hot data fits in one cache server's memory. 20 TB doesn't, so you need a cluster, or a CDN (Chapter 26).
- Read-heavy traffic points you to caches and replicas. Write-heavy traffic points you to queues and partitioning.
In an interview, estimates also prove you're designing for this problem, not reciting a generic diagram. And you don't need precision: you need the right order of magnitude (the number of zeros).
Memory code: "Size decides shape." The numbers don't just tell you how big to build. They tell you what to build.