Back-of-the-envelope estimation

A maps app has 200 million daily users. Before anyone draws boxes and arrows, someone has to ask: how many requests a second is that? A hundred? A million? The answer decides everything after it. A hundred fits on one machine, while a million needs a fleet, caches and careful sharding.

You don't need a spreadsheet to answer. A few known facts, round numbers and a minute of arithmetic get you to the right power of ten, and that is all the first sketch of a design needs. This is back-of-the-envelope estimation (also called Fermi estimation, after the physicist who was famous for it). It is the first step of every system-design interview and of real capacity planning, and this lesson gives you the method, the numbers to remember and practice.

daily active users (DAU)

How many people use the product on a typical day. Most estimates start here.

QPS

Queries (requests) per second. Traffic per day divided by the seconds in a day gives the average.

peak factor

How much busier the busiest time is than the daily average: often 2 to 10 times, more during a launch or a big event.

order of magnitude

The power of ten a number is closest to. 23,000 and 40,000 are both about 10^4; an estimate aims to get this right.

headroom

Spare capacity on purpose: servers planned to run well below 100% at the peak, because latency explodes near full load.

hot set

The small share of data that gets most of the traffic. Often about 20% of the keys get 80% of the reads, so a cache only needs the hot set.

Start with what you know and multiply your way to what you need, keeping the units in sight:

• Requests a day = daily users × requests each. 200 million users × 10 tiles = 2 × 10^9 requests a day.
• Requests a second = requests a day ÷ seconds in a day. A day has 86,400 seconds; call it 10^5. So 2 × 10^9 ÷ 10^5 = 2 × 10^4: about 20,000 requests a second. (The exact figure, 23,100, is the same power of ten.)

Try one. Type your estimate in any form you like (23000, 23k, 2e4), then compare your working with the steps.

Once you know the traffic, it is tempting to divide by what one server can do and stop there. But a server planned at 100% of its capacity has no slack to work a line down. Here one server is 95% busy: its service time is 100 ms, yet a request takes about 2 seconds on average, 20 times as long. The player stops before arrivals and asks whether each one will wait.

That is why capacity estimates divide by a target load, often 50–70% of what a server can do flat out, and then add a spare or two so the service survives a machine failing at the peak.

Traffic follows the clock: evenings, Monday mornings, a big match or a launch. Size the system for its peak. Find the average, multiply by a peak factor, then divide by what one server can do at its target load.

Storage is items × size × time, then × the number of copies kept. Bandwidth is requests a second × bytes per response. Remember the prefixes: 10^3 is kilo, 10^6 mega, 10^9 giga, 10^12 tera and 10^15 peta. And networks are sold in bits: multiply bytes by 8.

Every design is built on a few physical facts, which between them span about six powers of ten. They come from Jeff Dean's well-known list, and exact values vary with the hardware:

• a main-memory reference takes about 100 ns;
• a random read from an SSD takes about 100 µs, a thousand times slower;
• a round trip within a data centre takes about 0.5 ms;
• a disk seek takes about 10 ms;
• a round trip from California to Europe and back takes about 150 ms.

The estimation drills page has the full table.

These gaps are why caches exist. Reads are skewed (often 80% of them go to 20% of the keys), so keeping the hot 20% in memory answers most reads in microseconds instead of milliseconds.

• Requests a second = daily users × requests each ÷ 10^5 (a day is 86,400 seconds).
• Size for the peak, not the average, and plan servers at 50–70% of their capacity, with spares.
• Storage = items × size × time × copies; bandwidth = requests a second × bytes each (× 8 for bits).
• Memory (~100 ns), SSD (~100 µs), a data-centre round trip (~0.5 ms), a disk seek (~10 ms) and an ocean crossing (~150 ms) span about six powers of ten. Count the slow steps on a request's path.
• Round to one digit and a power of ten. Within 2× is excellent; within 10× still picks the right design.
• More practice: the estimation drills.