Step 2 of 14 · 1 min

What estimation is for

The point isn't to get the right number. You can't: you don't know how many users you'll have, how often they'll post, or how big their photos will be. The point is to find out which decisions the numbers force, and which ones they don't.

If the answer comes out as "about 10 writes per second," it doesn't matter whether the true number is 5 or 30. Any database handles that. If it comes out as "about 50,000 writes per second," it doesn't matter whether it's 30,000 or 80,000 either. You need a very different design. Estimation tells you which side of a line you're on, and the lines are usually far apart.

That's why it's fine to round aggressively. Being off by 2× rarely changes a design. Being off by 100× does, and estimation catches that.

Step 3 of 14 · 1 min

The few numbers you need

Seconds in a day: 86,400. Round it to 100,000. It makes the arithmetic easy, and the 15% error doesn't matter.

That gives a handy conversion:

Traffic isn't flat. People use apps in the evening more than at 4 am, and more on weekends and holidays. A peak of 2–3× the daily average is a reasonable starting point for most apps. For anything tied to events (a sports final, New Year's Eve, a big product launch), it can be 10× or more for short periods. Design for the peak, not the average.

Sizes, in powers of a thousand:

Bits and bytes. Network speeds are quoted in bits per second, storage in bytes. There are 8 bits in a byte. "1 Gbps" is 125 MB per second, not 1,000. Mixing these up is the most common estimation mistake there is, and it's an 8× error.

Step 4 of 14 · 1 min

The method

Every estimate follows the same chain. Start from people, end at machines:

1. Users: how many use the app on a typical day?
2. Actions: what do they do, and how often?
3. Requests per second: actions per day ÷ 100,000, then multiply for the peak.
4. Storage: what does each action save, and for how long?
5. Bandwidth: how much data moves for each action?
6. Memory: what needs to be fast, and how big is it?

Write every assumption down. When someone disagrees, you'll be able to see exactly which assumption they disagree with, and change it, instead of arguing about the conclusion.

Step 5 of 14 · 3 min

Chirp's napkin

Meera and Arjun agreed on an optimistic target: 1 million daily active users in a year. Here's the napkin, written out properly.

Assumptions

• 1M daily active users
• 10% of them post on a given day, about 2 posts each
• Everyone opens the feed about 10 times a day
• 20% of posts include a photo
• A post (text plus metadata) is about 1 KB in the database, including indexes
• A photo is about 500 KB after compression, and Chirp stores it in 3 sizes (original, feed size, thumbnail), adding about 50% more
• The feed shows about 10 photos per screen, each about 100 KB at feed size
• Peak is 3× average

Requests

Posts:       1M × 10% × 2    = 200,000 per day  → about 2 per second  (peak ~6)
Feed opens:  1M × 10         = 10M per day      → about 100 per second (peak ~300)

Each feed open also triggers a few other API calls (profile, notifications, and so on). Call it 5 calls per open: about 500 requests per second on average, 1,500 at peak.

Is that a lot?

This is where lesson 1.2 comes in. A single modern application server running ordinary code can handle somewhere in the hundreds to low thousands of simple requests per second. A single well-configured Postgres server can handle thousands of simple reads and writes per second, more if most data fits in memory.

6 writes per second is nothing. 1,500 requests per second at peak needs maybe two or three application servers, and you'd want at least two anyway so the app stays up when one fails. The database load is comfortable for one server.

Arjun's Cassandra cluster is designed for hundreds of thousands of writes per second. Chirp, at its optimistic one-year target, needs six.

Storage

Post text:  200K posts/day × 1 KB         = 200 MB per day  → about 75 GB per year
Photos:     200K × 20% = 40K photos/day
            40K × 500 KB × 1.5 (3 sizes)  = 30 GB per day   → about 11 TB per year

Look at how different those are. All the text Chirp will store in a year fits on a laptop. The photos are 150 times bigger.

Don't forget the multipliers that real systems add:

• Replicas: you'll want at least one copy of the database on another machine (lesson 2.5). ×2.
• Backups: at least one more copy somewhere else. ×1 more.
• Growth: you're estimating the first year, but storage keeps everything from every year.

So the database is about 75 GB × 3 ≈ 225 GB after a year. One server, easily. The photos are about 11 TB a year, growing every year, and they clearly don't belong in the database at all. That's exactly decision D2 in the Stage 0 simulation: where to store images. Lesson 2.3 is about the answer, object storage.

Bandwidth: the surprise

This is the line that ended the argument.

Feed opens:  10M per day
Photos seen: 10 per open × 100 KB = 1 MB per open
Total:       10M × 1 MB = 10 TB per day of photos sent to phones

Turn that into a rate:

10 TB/day ÷ 100,000 s ≈ 100 MB/s ≈ 800 Mbps on average
                                   ≈ 2.4 Gbps at peak

Then turn it into money. Cloud providers charge for data leaving their network, often somewhere in the range of $0.05 to $0.09 per GB at this kind of volume (check your provider; prices change and drop with volume):

10 TB/day × 30 days = 300 TB/month = 300,000 GB
300,000 GB × $0.05–0.09 ≈ $15,000–27,000 per month

Neither founder had put photos in their mental picture of "scaling." Arjun was worried about the database. Meera was worried about wasted engineering time. Meanwhile, the thing that would actually threaten Chirp's bank account at a million users was sending pictures to phones.

That changed the plan more than anything else on the napkin. It meant photos needed to be resized carefully (a thumbnail doesn't need to be 100 KB), served with good compression, and delivered through a CDN, which caches files near users and usually costs less per GB than serving them from your own servers (lesson 2.3). It also meant they should track bandwidth cost from day one.

Memory

What needs to be fast? The data behind the most frequent requests: profiles of active users, recent posts, the social graph for active users.

Active user profiles:  1M × 1 KB  = 1 GB
Last 2 days of posts:  400K × 1 KB = 400 MB

That's a couple of gigabytes, which fits in RAM on one ordinary server. A cache will be easy when they need it (lesson 2.4).

Step 6 of 14 · 1 min

From the real world: 50 times the plan

Here's what it looks like when a careful estimate meets a viral launch. Pokémon GO launched in July 2016, running on Google Cloud. Google later described the numbers: the teams had planned for a launch target of 1×, with a worst case of roughly 5× that. Actual traffic reached about 50× the target, ten times the worst case.

The first days had long stretches where players couldn't log in or the game wouldn't respond. Google's reliability engineers worked alongside Niantic, the game's developer, to add capacity ahead of the growth, many tens of thousands of CPU cores for the game's container cluster, and to fix bottlenecks as each new one appeared.

Two lessons for your own napkin:

• An estimate is a range, and you need a plan for being outside it. Nobody could have predicted 50×. But you can decide in advance what happens at 10× the worst case: which features turn off, whether logins queue instead of failing, which limits you'll raise. Pokémon GO's teams were rebuilding pieces under live load because there wasn't that plan.
• Your estimate's biggest number is the one you're least sure of. Daily users times actions per user is easy arithmetic on two guesses. Write down which of your inputs is the shakiest, and how the design changes if it's wrong by 10×. Usually only one or two parts of the system care (here: login, and the map data around each player), and those are the parts to design with room to grow.

For Chirp, Meera's rule became: "Estimate it. Then ask what breaks first at ten times that, and what we'd do. If the answer is 'rewrite everything,' we've designed it wrong."

Step 7 of 14 · 1 min

Going deeper: why 90% busy is not "10% spare"

The method says to divide peak load by what one server handles. There's a catch: how busy you let each server get changes how fast it answers, and not in a straight line.

Requests don't arrive evenly. Even at an average of 800 a second, some milliseconds bring a burst, and a burst has to wait in a queue. The busier the server, the more likely a new request finds others ahead of it. For the simplest model of random arrivals (called M/M/1 by queueing theorists), the average time a request spends in the system is:

time in system = work time ÷ (1 − utilization)

At 50% busy, a request spends twice its own work time in the system. At 80%, five times. At 90%, ten times. At 95%, twenty. And p99 is several times worse than those averages. The last few percent of capacity cost as much latency as everything before them.

Switch the diagram to one shared queue and you'll see the second, more hopeful result. Eight servers each with their own queue behave like eight separate M/M/1 queues: a request stuck behind a slow one waits, even if a neighbour is idle. Eight servers pulling from one shared queue (M/M/8) behave far better at the same utilization: at 80% busy, time in system is about 1.2× the work time instead of 5×. This is why a load balancer that sends work to whichever server is free beats a fixed assignment, and why one big connection pool beats many small ones.

What this means for estimates:

• Plan for 60–70% at peak, not 100%. The "spare" capacity is what keeps latency flat.
• Pool where you can. Shared queues, shared pools and least-loaded routing get more out of the same machines.
• When something gets slower, it gets busier, and then slower still. That loop is behind many outages in Part 6.

Step 8 of 14 · 1 min

What the napkin decided

Meera was right about the servers and database. Arjun was right that some things need planning up front: they just weren't the things he'd been reading about. Getting photo storage wrong early would be painful to undo, so it was worth doing properly from the start. Kubernetes could wait.

And if Chirp ever did get to 50 million users, they'd redo the napkin, and it would point to different decisions. That's the rest of this course.

Step 9 of 14 · 1 min

Run your own napkin

Here's Chirp's napkin with the assumptions turned into sliders. Push the number of users up and see what breaks first. Then try the photo size and see how much it moves the bill compared with everything else.

Step 10 of 14 · 1 min

Where estimates go wrong

Forgetting the peak. An app that averages 100 requests per second and peaks at 1,000 needs to be designed for 1,000. Events make this worse: the moment a big match ends, everyone opens the app at once.

Forgetting the multipliers. Replicas, backups, indexes, logs, the three sizes of every photo. Storage estimates are often low by 3–5× because of these.

Bits versus bytes. An 8× error, in either direction, from one letter.

Using the average user. Most users are light, and a few are very heavy. For capacity, totals are what matter, so averages are fine. For the worst case on a single machine (the most-followed account, the busiest chat room), you need to think about the heaviest user, not the average one. Lesson 4.4 is entirely about this.

False precision. "We need 3.72 TB" sounds more serious than "about 4 TB," but it isn't more accurate. It just makes it harder to notice that an assumption was a guess.

Forgetting to sanity-check. When you get a number, compare it with something you know. "10 TB a day of photo traffic for a million users" works out to about 10 MB per person per day, which is roughly 100 photos. For someone who scrolls a social feed several times a day, that's believable. If it had come out as 10 GB per person, something would clearly be wrong.

Step 11 of 14 · 1 min

In the simulation

At the start of Stage 0 you'll see Chirp's assumptions: users, posting rate, photo share, and so on. Before you make your first decisions, do the napkin math yourself and write it down. When you reach later stages and things start breaking, go back and check: was it a number you could have estimated? Most of the time, it will be.

Open the simulation →

Step 12 of 14 · 1 min

If you're here for an interview

Most design interviews include a few minutes of estimation, and candidates often get it wrong in one of two ways: they skip it, or they spend ten minutes on arithmetic nobody needed.

What works well:

• Estimate only what changes the design. Requests per second, storage size, and bandwidth usually matter. Exact memory per server usually doesn't.
• Round loudly and say so. "That's about 100,000 seconds a day, so 10 million a day is about 100 per second."
• Say what the number means. "That's about 6 writes per second, which one database handles easily, so I won't shard." The conclusion is the point; the arithmetic is just how you got there.
• Look for the surprise. In many problems one dimension dominates, like bandwidth for Chirp. Finding it early shows you understand where the real cost is.

Step 13 of 14 · 2 min

Try these yourself

Step 14 of 14 · 1 min

Further reading

• Jeff Dean's talks on designing large systems include his classic estimation examples (search for "Jeff Dean back of the envelope").
• Your cloud provider's pricing pages for storage and data transfer, the real inputs for any cost estimate.
• The Art of Capacity Planning by John Allspaw, written from his experience running Flickr's infrastructure.
• Luke Stone, "Bringing Pokémon GO to life on Google Cloud," Google Cloud blog, 2016. The source of the 1×, 5× and 50× figures.
• Mor Harchol-Balter, Performance Modeling and Design of Computer Systems, chapters on M/M/1 and M/M/k. The pooling result is in the M/M/k chapter.