Back-of-the-Envelope Numbers

The problem: numbers you can't feel

Almost every system design interview has a moment where the interviewer says "10 million daily active users" and waits. That number alone doesn't tell you whether one database is enough, whether you need a cache, or how many disks the photos will fill. Back-of-the-envelope estimation turns it into the numbers a design is built from: requests a second, storage and bandwidth.

The catch is that daily totals sound enormous. Ten million lookups a day looks like far too much for a database server that answers about 5,000 lookups a second, but a day has 86,400 seconds: 10 million a day is only about 116 a second. Comparing a day's total with a per-second limit is the most common estimation mistake, so the first rule is to put everything in the same unit.

No interviewer wants exact arithmetic. They want sizes you can reason with, worked out in your head, in a few minutes.

How it works: four tricks

A day is about 100,000 seconds

A day really has 86,400 seconds. Round it to 100,000 and dividing by a day becomes dropping five zeros: 1 billion a day ÷ 100,000 is 10,000 a second. The answer comes out about 14% low (the real figure is about 11,600), which never changes a design. Two conversions worth remembering: 1 million a day ≈ 12 a second, and a month is about 2.6 million seconds.

Powers of ten

Counts and sizes climb in steps of 1,000: thousand, million, billion, trillion, and for bytes KB, MB, GB, TB, PB. A million is two steps (1,000 × 1,000), so 1 million photos of 1 MB are 1 million MB: two steps up from MB, which is 1 TB. Most unit mistakes come from moving one step instead of two.

One significant figure

Round every number to one significant figure as you go: 365 days becomes 400, 11,574 becomes 10,000, 1,825 TB becomes 2 PB. The day's 86,400 seconds go one step further, to the power of ten 100,000, because dividing by it is just dropping zeros. The error stays small next to the guesses you started from, and the arithmetic stays simple enough to do while you talk.

The peak is about 5× the average

Traffic follows the day: busy evenings, quiet nights, spikes when something big happens. A common rule in interviews is to plan for about 5× the average at the busiest time, unless the interviewer gives you a different number.

A worked example: a photo-sharing app

The interviewer's numbers: 10 million daily active users, each viewing about 100 photos a day; 1 in 10 users posts one photo a day; a photo is about 1 MB.

Views a day        10 million × 100       = 1 billion
Views a second     1 billion ÷ 100,000    ≈ 10,000   (11,600 with 86,400)
At the busy hour   5 × 10,000             ≈ 50,000 a second
Uploads a day      10 million ÷ 10        = 1 million
Uploads a second   1 million ÷ 100,000    ≈ 10       (12 with 86,400)
Storage a day      1 million × 1 MB       = 1 TB
Storage a year     1 TB × 400             ≈ 400 TB
Storage, 5 years   400 TB × 5             ≈ 2 PB
Bandwidth out      10,000 × 1 MB          = 10 GB a second (≈ 50 GB at peak)
Bandwidth in       10 × 1 MB              = 10 MB a second

Views outnumber uploads 1,000 to 1: the app is read-heavy, so the read path is the one to make fast. The numbers that matter are not the users but the 50,000 lookups a second at peak, the 2 PB of photos and the 50 GB a second going out.

The wrong turns people really make here: dividing by a month's seconds instead of a day's (about 400 a second instead of 10,000), forgetting that only 1 in 10 users posts (10 TB a day instead of 1), or moving one step on the size ladder instead of two (1 GB instead of 1 TB).

The choices and their trade-offs

• Peak or total. Anything that must answer in time, like database servers, app servers and the network, is sized for the peak, or it fails at the busiest hour. Anything that only piles up, like disk and the number of records, uses the total: the daily total already includes the busy hours.
• Quick or exact. 100,000 seconds instead of 86,400 is about 14% low, far less than the error in the 5× peak or the interviewer's guesses. Say "about" and move on; if a result lands close to a limit, say which way you rounded.
• Files and records apart. Each photo also has a record (who posted it, when, where the file is) of about 500 bytes. At 1 million a day that is 500 MB a day, about 1 TB over 5 years: one database holds it easily, while the files take 2 PB. Estimating them apart shows they belong in different stores.
• Copies. Many systems keep three copies of stored data so a broken disk loses nothing, which turns 2 PB into about 6 PB of disk. Mention it when the interviewer asks about raw disk.
• Assumptions out loud. Say one database server answers about 5,000 lookups a second, one cache server about 100,000, one app server about 1,000 requests a second, and one server's network sends about 1 GB a second. Stating them lets the interviewer correct a number instead of the whole design.

Where it shows up in design interviews

In the interview framework (Scope, Data, API, The busy path, Numbers, Services, Scale, Deep dives) the numbers come fifth, once you know which path is busy. Their job is to decide the design, so finish each estimate by saying what it means:

• About 10 uploads a second and 10 GB of user profiles (10 million × 1 KB): one server handles each, so keep it simple.
• About 50,000 photo lookups a second at peak: one database server answers about 5,000, so you need about 10 of them, or a cache in memory in front.
• About 2 PB of photos: storage spread over many machines (object storage), not rows in a database.
• About 50 GB a second going out at peak: about 50 servers' worth of network, so photos go out through a CDN, copies kept on servers near the users.

Keep the whole thing to a few minutes: the interviewer is checking that your design fits real traffic, not your arithmetic.

Common interview questions

How many servers do we need?

Divide the peak rate by what one server handles, and state that capacity as an assumption. At 50,000 lookups a second and about 5,000 per database server, that is about 10 database servers; at about 1,000 requests a second per app server, about 50 app servers.

Why not plan for the average?

Because the average hides the busy hours. Servers sized for 10,000 a second would be overloaded every evening at 50,000. The average is right only for totals, like storage.

How precise should the estimates be?

One significant figure is enough: the inputs are guesses, and a design changes when a number is 10× off, rarely when it is 14% off. Round as you go and say "about".

How much storage over 5 years?

Take a day, multiply by 400 for a year (365 rounded), then by 5. For the photo app: 1 TB a day, about 400 TB a year, about 2 PB in 5 years, about 6 PB with three copies.

What if the interviewer gives no numbers?

Propose them and check: "Say 10 million daily users, each viewing 100 photos a day. Does that sound right?" An assumption the interviewer agrees with is as good as a given number.

Summary

• Per second: users × actions per user ÷ 100,000 (86,400, really); 1 million a day ≈ 12 a second.
• Peak: about 5× the average; size servers and network for it.
• Sizes: KB, MB, GB, TB, PB, each 1,000× the one before; a million is two steps.
• Storage: a day × 400 for a year, × 5 for 5 years; totals, not peaks.
• Bandwidth: requests a second × the size of each answer.
• Rounding: one significant figure, no calculator.
• Then decide: one server or many, cache or not, in a few minutes.