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.10 How much memory does the cache need?
3 min read+10 XP
At the wedding: You don't put every dish at the front counter. You keep the few popular ones there, the ones most guests ask for, and fetch the rest from the kitchen.
In the system: Requests usually aren't spread evenly. A small share of the data gets most of the reads. A common rule of thumb is 80/20: roughly 20% of the data gets 80% of the traffic. It's a starting assumption, not a law, so say it as one.
So: cache about 20% of a day's read data.
PicShare's metadata reads: 500 million views × 1 KB = 500 GB a day.
- 20% of that = 100 GB. That fits in the memory of one large cache server or a small cluster (Chapter 12).
PicShare's image reads: 500 million × 200 KB = 100 TB a day.
- 20% of that = 20 TB. That's far too big for a normal cache cluster, which is another reason images go through a CDN, a cache built for big files spread across the world.
Memory code: "Cache the hot 20%." And check whether it fits in memory before you promise it.