Lesson 1.2 · 10 min

Back-of-the-envelope math

Feel the latency ladder from nanoseconds to an ocean crossing, and turn daily users into QPS and storage in seconds.

The idea in plain words

Before building anything, engineers do quick, rough math to see if a design can work: how many requests per second, how much storage, how many servers. The goal is the right order of magnitude, not an exact number.

The problem it solves

In a design interview you have to decide things like “one database or ten?” before anything is built. Rough numbers tell you which problems are real at this scale and which you can ignore.

How it works

1. Start from users: daily active users × actions per user = actions per day.
2. Divide by about 100,000 (the seconds in a day, rounded) to get the average per second.
3. Multiply by 2–3 for the busiest hour.
4. Multiply size per item × items per day × days kept to get storage.
5. Compare against what one machine can do to see how many you need.

Example

10 million users each post 2 times a day = 20 million posts a day ≈ 200 per second, about 600 per second at peak. One database can handle that. At 1 KB each, a year is about 7 TB, which is fine for a few machines but worth planning for.

Key terms

QPS

Queries (requests) per second: how busy a system is.

Latency

How long one operation takes, from asking to getting the answer.

Peak traffic

The busiest moments, usually 2–3× the daily average; design for these.

Order of magnitude

Roughly how big, in powers of ten: 10, 1,000 or 1,000,000.

In this lesson you'll learn

• Know which operations are fast and which are slow.
• Turn daily users into requests per second, storage and server count.
• Do the math quickly enough to say it out loud in an interview.

Sections

1. The latency ladder
2. Estimate like an interviewer
3. Check yourself

Cheat sheet

The interactive simulations and the quiz load with JavaScript.