Most candidates skip estimation in a system design round. They jump straight to drawing boxes. Then the interviewer asks "how many servers do you need?" and there's an awkward pause.
Estimation is the part that turns a vague prompt into a real design. If you know your system handles 5,000 writes per second and stores 50 TB a year, your choices about databases, caching, and sharding stop being guesses. They become decisions you can defend.
Here's how I do it under time pressure.
Start by pinning down the numbers you actually need
Don't estimate everything. For most designs you need four numbers:
- Queries per second (QPS), split into reads and writes
- Storage growth per year
- Bandwidth (read and write throughput in bytes)
- Maybe memory, if you're going to cache
Everything else is derived from these or doesn't matter yet. Pick the ones the design hinges on and ignore the rest.
Anchor on users, then work down to per-second numbers
You almost always start with a user count, because that's the number interviewers hand you or that you can ask for. Say the interviewer says "design a URL shortener." Ask: how many users, or how many new URLs per day?
If they shrug and say "you tell me," pick a number out loud and commit to it. "Let's say 100 million daily active users." Now you have an anchor, and everything flows from it.
To get to QPS, take a daily count and divide by the seconds in a day. The number to memorize is that a day has about 86,400 seconds. I round it to 100,000 to make the math easy. That rounding is fine and interviewers expect it.
So 1 billion requests a day is roughly 1 billion / 100,000 = 10,000 QPS. That's the whole trick. Daily total divided by 100k gives you average QPS.
Don't forget the peak
Average QPS is not what your system has to survive. Traffic clumps. A common move is to assume peak is 2x to 3x the average and size for that. Say it out loud: "average is 10,000 QPS, I'll provision for a peak of about 25,000."
You don't need a precise multiplier. You need to show you know average and peak are different.
Get the read/write ratio right early
This one changes the whole design, so I figure it out before anything else. A URL shortener is read-heavy, maybe 100 reads for every write. A logging system is write-heavy. A social feed is read-heavy with expensive reads.
If reads dominate, you lean on caching and read replicas. If writes dominate, you think about write throughput, batching, and partitioning. State the ratio, then let it drive your storage and caching story.
Estimate storage with one row times the count
Storage is the easiest one. Estimate the size of a single record, then multiply by how many you create.
For the URL shortener, one record might be a short code, the long URL, a timestamp, and a user id. Call it about 500 bytes to be safe. If you create 100 million new URLs a day, that's 100 million times 500 bytes, which is 50 GB a day. Over a year that's roughly 18 TB.
Now you can talk credibly about whether this fits on one machine (it won't long term) and when you'd need to shard.
Round hard and keep your units straight
Two things blow up estimation answers under pressure.
The first is arithmetic. Round everything to powers of ten and round early. Use 100k seconds per day, 1 million users, nice clean figures. Nobody cares if the real answer is 47,000 instead of 50,000.
The second is units. Bits versus bytes, KB versus MB, per day versus per second. Most embarrassing mistakes come from a units slip, not bad reasoning. Write the units next to every number on the whiteboard. It catches errors and it shows the interviewer you're being careful.
A cheat sheet worth knowing cold: KB is a thousand bytes, MB is a million, GB is a billion, TB is a trillion. Each step up is roughly three zeros.
Tie every number back to a decision
Estimation isn't a separate phase you do to look thorough. It's the justification for your design.
After each number, say what it implies. "50 GB a day means a single Postgres instance is fine for the first year, so I won't shard yet." "25,000 QPS at the read layer means I need a cache in front, because hitting the database for every read won't hold up."
That connection is what interviewers are actually grading. The arithmetic is easy. Using the result to make a defensible choice is the skill.
How to get faster at this
The math is simple but it feels slow the first few times because you're translating in your head while talking. The fix is reps.
Pick three or four common designs (a shortener, a feed, a chat app, a rate limiter) and run the estimation out loud until the numbers come without stalling. Doing it in a mock interview, where someone pushes back on your assumptions, surfaces the gaps faster than doing it alone.
Once the back-of-the-envelope part is automatic, the rest of the round gets a lot calmer. You stop guessing at scale and start designing for it.