Back-of-the-Envelope Estimation

A candidate designing a photo-sharing app is told "10 million daily users". They spend four minutes dividing by 86,400, get 3,472.2 requests a second, and then draw the design they would have drawn for 30 or for 300,000. The interviewer learned nothing about their judgment.

Estimation has one job: find out which numbers are big enough to change the design. You want the right order of magnitude in under four minutes, out loud, and then a sentence that starts "so...".

#The handful of facts you need

Almost every estimate is built from these conversions. Memorize them.

The powers of two drift from the powers of ten (2⁴⁰ is about 10% more than 10¹²), which never matters at this precision. Interviews use powers of ten: 1 KB = 1,000 bytes.

• A day is about 100,000 seconds. The real figure is 86,400. Dividing by 100,000 gives rates about 14% low; say so once and move on.
• A month is about 2.5 million seconds (30 × 86,400 ≈ 2.6 million). A year is about 30 million (365 × 86,400 ≈ 31.5 million).
• 1 million a day is about 10 a second. 1 billion a month is about 400 a second.
• Sizes: an ASCII character is 1 byte, an integer or a timestamp 8 bytes, a UUID 16 bytes. A small database row is a few hundred bytes. Photo sizes and server capacity are for the interviewer to give or for you to state as assumptions.

Latency figures (a memory read, a disk seek, a cross-region round trip) live in numbers to know.

#From daily users to servers

The core chain: daily users times actions per user gives requests a day; divide by 100,000 for the average rate; multiply by a peak factor; divide by what one server handles. Step through it for the photo app.

requests/day = daily users × requests per useraverage QPS  = requests/day ÷ 100,000peak QPS     = average QPS × peak factorservers      = peak QPS ÷ QPS per server ÷ 0.7

Each number should end with "so": so it fits on one machine, so it needs a CDN, so we must partition.

#Storage, bandwidth and memory

Storage is items a day × bytes per item × days kept × copies. Bandwidth is requests a second × bytes per response. Cache memory is the number of hot items × bytes per item. Try each before opening the answer.

Two traps on the way. Network links are quoted in bits a second and storage in bytes: multiply bytes by 8. And durable storage almost always keeps more than one copy, so state your replication factor or the storage figure is a third of the real one.

#How precise to be

What would make you more careful: a number close to a real limit. If peak traffic comes out at 900 a second and your assumed single-server limit is 1,000, the rounding matters; say "that is close to one server's limit, so I'll plan for two or more".

#In the interview

Estimate after clarifying and before the API, as in the framework. Ask for the inputs, state any you assume, and compute only what can change the design: usually peak rate, total storage, and bandwidth or cache size.

• "I'll round a day to 100,000 seconds, so my rates are a bit low."
• "That's 1 GB a second of images, so images go through a CDN and never touch the API servers."
• "Storage is 1 PB a year, so photos go in blob storage and the database only holds metadata."

Follow-ups you should expect:

• "Where does a peak factor of 3 come from?" It is an assumption about daily patterns. Say what would raise it: a single time zone, a live event, a launch.
• "How sure are you?" "Within a factor of 2 or 3, which is enough to choose the architecture."

#Common mistakes

#What to practice next

Next, turn the requirements into endpoints in API Design. For the estimates in a full case, see Design Video Streaming, where bandwidth drives everything.