A Worked Estimation Example

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.

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.

Those are averages, and bandwidth has to be provisioned for the peak. At three times average that is 150 MB per second in and 15 GB per second out. Fifteen gigabytes per second leaving the origin is the single most important result in this calculation. Storage is the exception: a day of uploads is 5 TB whether it arrives smoothly or in bursts, so the peak factor does not apply to the storage numbers.

Cache

There are two caches here, and they hold very different things.

The photos being looked at are mostly recent ones. Take the last day of uploads, 10 million photos, and assume a fifth of them get most of the views. That is 2 million popular photos.

The photo bytes. 2 million photos times 500 KB is about 1 TB. The CDN keeps these on its edge servers, close to users. Image files are too large for the in-memory cache in front of the database.

The photo records. That cache holds the small record for each photo: who posted it, where the file is stored, the caption, the like count. At about 1 KB per record, 2 million records is about 2 GB, small enough to keep in memory.

What the numbers changed

This is the part that matters. Four calculations produced four design decisions.

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 on average, and three times that at peak. The 2 million popular photos take about 1 TB, which the CDN edges keep, while their records take only about 2 GB in the cache in front of the database. Those results force a cache for the records, a CDN for the bytes, and object storage for everything kept, 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.