Picture a shopkeeper who, before ordering stock, asks "how many customers a day, roughly?" She doesn't need the exact number. She needs to know if she's stocking a corner shop or a supermarket. Estimation in a system design interview is that same quick check, done with rough numbers in three minutes. Nobody checks your arithmetic. The only question that matters is: is this a one-machine problem, a one-rack-of-machines problem, or a thousand-machine problem? The answer decides everything you draw next.

This lesson gives you a set of numbers worth memorising, four shortcuts for doing the maths fast, and three worked examples to pattern-match against.

The numbers worth memorising

Learn these two tables once. They cover almost every estimate you'll ever do at a whiteboard.

Picture two friends. One passes a note across the same classroom; the other mails a letter to a friend in another country. The classroom note is like reading from computer memory: almost instant. The international letter is like a network call to a server on another continent: it takes far, far longer. That speed gap is the entire reason system design keeps data close to whoever is asking for it.

Latency, the time one operation takes. These are rounded on purpose, because round numbers are what you actually need to remember:

Here ns means nanosecond (a billionth of a second), µs means microsecond (a millionth of a second), and ms means millisecond (a thousandth of a second).

Three ratios matter more than the exact numbers: memory is roughly 100 times faster than SSD, SSD is roughly 100 times faster than a spinning disk, and a trip across a continent costs more than 100,000 memory reads. That last fact is the whole reason you cache data, batch requests together, and avoid chatty calls between services in different regions.

How much one ordinary machine can handle, before you need a second one:

Round aggressively. If someone else says "8,000 queries per second on one Postgres node" and you said 10,000, nothing about your design changes. That's the whole point of rounding.

Remember: memory beats SSD by about 100 times, SSD beats a spinning disk by about 100 times, and a cross-continent trip costs more than 100,000 memory reads. That's why you cache data close to the user.

Four arithmetic shortcuts

These four turn estimation from real maths into something you just remember.

1. Powers of two match common data sizes.

2. A day has about 100,000 seconds. It's really 86,400, but rounding up to 100,000 makes the mental maths easy. So 1 million events a day is about 10 a second, and 1 billion a day is about 10,000 a second. Nearly every "how many per second" question you'll ever answer is a version of one of those two.

3. The busiest moment is 2 to 3 times the average. Real traffic rises and falls through the day, like a shop that's quiet at 3am and busy at 7pm. Design your system to survive the busy peak, but estimate cost using the average. If a big launch or a sale is part of the scenario, use 10 times instead of 2 to 3.

4. Typical sizes let you turn "how many requests" into "how many bytes."

One habit that follows from this: storage for a year is roughly bytes-per-day multiplied by 400 (365 rounded up), and multiply again by 3 if you keep extra copies of the data.

Remember: a million events a day is about 10 a second. A billion a day is about 10,000 a second. Multiply by 2 to 3 for the busiest moments of the day.

The estimation template

Run through the same five lines every time, in this order, and say each one out loud. Each line is a chance to earn a point.

Here DAU means daily active users, and QPS means queries (or requests) per second.

Then do the part most people forget: say the conclusion out loud. An estimate with no conclusion has earned nothing. Examples of a real conclusion:

• "3,500 requests a second at peak is a handful of app servers, not a thousand. I'm not building Google here."
• "100 reads for every write, so caching and extra read copies carry this design."
• "50 terabytes of video a year means the files live in object storage behind a CDN, and the database only stores information about them."
• "One database shard tops out around 10,000 requests a second, so at 40,000 I need at least 4 to 8 shards plus some spare room."

There's a fifth conclusion worth practising, because it's the bravest and most senior one to say: "these numbers are small. A single Postgres database with one backup copy for reads handles this easily, and I'd start there." Reaching for a big distributed system that the problem doesn't actually need is a real mistake, and interviewers do mark it down.

Remember: an estimate that doesn't end in a "so..." sentence wasted everyone's time. Numbers only matter for the decision they point to.

Three worked estimates

A. A read-heavy social feed, 10 million daily active users.

Conclusion: the text is a small problem. The photos and videos are the real storage and bandwidth problem. Build the read path around a cache, keep the files in object storage behind a CDN, and store only information about each file in the database.

B. Write-heavy metrics collection, 100,000 servers each sending one measurement a second.

Conclusion: a normal database table with one row per measurement can't keep up. This calls for a time-series database (one built for exactly this shape of data), which compresses data by column, batches writes together, and shrinks old data over time: full detail for a day, once-a-minute detail for a month, once-an-hour detail for a year. That cuts long-term storage by about 99%.

C. A video platform, 1 million uploads a day, 500 million views a day.

Conclusion: 75 gigabits per second cannot come straight from your own servers. The entire design has to be built around a CDN. Converting videos into different quality levels is a queue-and-worker problem, and the database that stores video titles and descriptions is by far the easiest part.

Notice the pattern across all three examples: the estimate points straight at one subsystem that's actually hard, and that subsystem becomes your deep dive later in the interview.

Remember: every worked estimate should end by pointing at one subsystem. That's the part worth designing carefully.

Quick recap