0% completed
A Worked Estimation Example
On This Page
The assumptions
Traffic
Storage
Bandwidth
Cache
What the numbers changed
When an assumption changes
Here is the whole method on one system. The case study: a photo sharing service. Users upload photos and view other people's photos.
The assumptions
Nothing can be calculated until these are on the board. Every one of them is a guess, and every one is stated so it can be challenged.
| Assumption | Value |
|---|---|
| Daily active users | 100 million |
| Share who upload a photo on a given day | 10 percent |
| Average size of a photo after compression | 500 KB |
| Reads for every write | 100 |
| How long photos are kept | 5 years |
| Copies kept of each photo | 3 |
| Peak traffic against average | 3x |
Traffic
Uploads per day are 100 million users times 10 percent, which is 10 million writes per day.
Divide by 100,000 seconds: 100 writes per second on average. At three times peak, 300 writes per second.
Reads are a hundred times writes, so 10,000 reads per second on average, and 30,000 reads per second at peak.
That first pair of numbers already says something. Three hundred writes per second is a small number that a handful of machines can absorb. Thirty thousand reads per second is not. This is a read heavy system, and the design should spend its effort on the read path.
Storage
Ten million photos per day at 500 KB each:
10 million times 500 KB is 5 TB per day.
Over a year that is 365 times 5 TB, which is about 1,825 TB, and rounding up, 2 PB per year. Over the five year retention period, 10 PB.
Then the multiplier that is easy to forget. Three copies of everything makes it 30 PB.
Bandwidth
Incoming is write traffic times object size: 100 writes per second times 500 KB is 50 MB per second.
Outgoing is read traffic times object size: 10,000 reads per second times 500 KB is 5 GB per second.
Those two numbers differ by a factor of a hundred, which is exactly the read to write ratio, and that is a good sign the arithmetic is consistent. Five gigabytes per second leaving the origin every second is the single most important result in this calculation.
Cache
The photos being looked at are mostly recent ones. Take the last day of uploads, 10 million photos, and assume a fifth of them account for most of the views.
2 million photos times 500 KB is about 1 TB of cache.
What the numbers changed
This is the part that matters. Four calculations produced four design decisions.
| Result | What it forces |
|---|---|
| 30,000 reads per second against 300 writes | A cache in front of the database, and read replicas behind it |
| 5 GB per second going out | A content delivery network, so most bytes are served near the user |
| 30 PB kept | Photos live in object storage, not in a relational database |
| 1 TB of hot data | The cache is distributed across machines, not one box |
Notice the third row. Thirty petabytes rules out keeping the image bytes in a database, which pushes you toward the standard split: the photo bytes go to object storage, and the database holds only the small record describing each photo. That decision came out of an arithmetic result, not out of a preference, and being able to say so is what the exercise is for.
When an assumption changes
Interviewers change one number to see whether you understood the calculation or memorized it.
Suppose half the users upload each day instead of a tenth. Uploads go from 10 million to 50 million per day, so every result multiplies by five. Writes become 500 per second, storage becomes 25 TB per day and 150 PB over five years, and outgoing bandwidth becomes 25 GB per second.
The conclusions do not change. It is still read heavy, it still needs a CDN, the photos still belong in object storage. A design that survives a five times change in the assumptions is a robust design, and saying that out loud is worth more than the recalculated numbers.
💡 Round while you calculate, not at the end. 1,825 TB becomes 2 PB immediately, and every later step is easier for it. Carrying three significant figures through an estimate built on guesses gives an impression of precision that the inputs cannot support.
Key takeaway: Working through the photo sharing case study: 100 million daily users at 10 percent upload rate gives 10 million writes per day, 100 writes per second, and at a 100 to 1 read ratio, 10,000 reads per second. At 500 KB per photo that is 5 TB per day, 10 PB over five years, and 30 PB with three copies. Bandwidth is 50 MB per second in and 5 GB per second out. A 1 TB cache holds the hot set. Those four results force a cache, a CDN, object storage for the bytes, and a distributed cache, and they keep forcing them even if the assumptions move by a factor of five.
That completes the chapter. The Flashcards Review and the Chapter Assessment are next.
On This Page
The assumptions
Traffic
Storage
Bandwidth
Cache
What the numbers changed
When an assumption changes