Capacity Estimation System Design Interview: Round Numbers

When an interviewer asks for capacity estimation in a system design interview, they are not testing arithmetic. They want to hear how you choose assumptions, round them, and use the result to steer the design. A rough answer in the right order of magnitude, with every assumption said out loud, beats a precise number with no reasoning behind it. Open with one line: "Let me state my assumptions first, then round hard." Then follow a four-step routine you can reuse on any system: assume, round, compute, conclude.

What interviewers actually want when they ask for capacity estimates

The estimate is a reasoning signal. The interviewer watches how you pick assumptions, whether you sanity-check them, and, most of all, whether the number changes what you build next. A candidate who says "about 10 QPS, so a single primary handles writes fine" has shown more than one who recites five precise figures and then moves on as if nothing happened.

Name the three things you are estimating, because they drive different decisions:

• Traffic: requests per second, split into reads and writes.
• Storage: bytes accumulated over time, which decides partitioning and retention.
• Bandwidth or connections: bytes per second moving in and out, which decides caching and edge placement.

Set your own expectation out loud. Say you will aim for the right order of magnitude, not exact figures. That gives you permission to round and tells the interviewer your numbers are deliberate rather than guessed.

The four-step method for capacity estimation in a system design interview

Use this checklist every time, and say each step as you do it.

1. Assume. State users, usage frequency, and item size. "Ten million daily users, one link created per user per week, about 500 bytes per record."
2. Round. Push every input to a power of ten. Ten million stays 10^7; one per week becomes roughly one-seventh per day, so round to 0.1 per day.
3. Compute. Derive read and write QPS and storage, keeping the exponents visible.
4. Conclude. Say what the number implies for the design. Every estimate ends here.

The arithmetic habits that keep you fast:

• A day is a useful round number of seconds. Treat it as a single power of ten so the division stays mental.
• A million requests a day is a small number of QPS. Round it down to a tidy power of ten rather than chasing the exact figure.
• The units ladder: bytes to KB to MB to GB to TB, each step roughly a thousand. Multiply by 10^3 per rung and you never lose the order of magnitude.

Here is a spoken template for each step: "Assume: ... Round: ... Compute: so that's about ... Conclude: which means we should ..." Rehearse the narration, not just the math. The words are what the interviewer scores.

A worked example: estimating a URL shortener out loud

Here is a full sample narration. Treat it as an illustration of the routine, not a script to memorise.

Let me state my assumptions first, then round hard. Ten million daily users. Each creates about one link per week, so roughly 0.1 links per day. Each link gets about ten redirects over its life, but let me spread reads as ten per link per day for a busy day. A record is about 500 bytes.

Writes: 10^7 users times 0.1 links per day is 10^6 writes per day. Divide by the seconds in a day and round hard, and that lands in the low tens of writes per second. Call it 10 QPS.

Reads: ten times the writes, so 10^7 reads per day, which rounds to about 100 QPS.

Storage: 10^6 links per day times 500 bytes is 5 times 10^8 bytes, so about 500 MB per day. Over five years that is a few hundred thousand days' worth of megabytes, which lands around a terabyte. Call it 1 TB.

So this is read-heavy by roughly one order of magnitude, and storage is small enough for one primary with a read replica and a cache in front. The reads are where I would spend complexity.

Now the same estimate, weak then stronger. The weak version: "Ten million users, so maybe a million writes a day, a hundred QPS reads, one terabyte of storage. Next I'll design the schema." It dumps numbers and stops. The stronger version ends with the consequence: "So this is read-heavy by roughly one order of magnitude, which pushes us toward caching and read replicas rather than sharding writes." Same arithmetic, different signal. The conclusion is the part the interviewer remembers.

How to connect the number to an architecture trade-off

A number is only useful when it points at a design move. Map your result to a decision and say the trade-off out loud.

Say the trade-off in one sentence: "At this write rate a single primary is probably fine, but the read volume is where I'd spend complexity." That sentence shows you can weigh cost against benefit, which is the core of architecture trade offs in a distributed systems interview.

When the read path dominates, the follow-on decisions have their own reasoning. Our consistency models walkthrough covers picking and defending a read guarantee when replicas multiply, and the CDN caching article covers pushing reads to the edge.

What to do when the interviewer challenges your assumptions

Changing an assumption is normal and shows collaboration, not error. The recovery move is simple: accept the new number, redo only the affected step, and restate the conclusion. Do not restart the whole estimate.

Challenge one: "Users are ten times higher." Your adjusted narration: "Fair, so 10^8 users. Writes go up tenfold, reads go up tenfold, and storage grows tenfold over five years. At that read volume I'd definitely cache and use several read replicas, and the larger storage starts to justify partitioning." You changed one input and followed it through.

Challenge two: "Each link is stored forever." Your adjusted narration: "Then storage is the binding constraint, not reads. Five years at 500 MB a day is still about 1 TB, but if retention is indefinite I'd revisit partitioning and add an archival tier." Notice you only redid the storage step and restated what it changes.

This is the capacity estimation interview explanation most candidates miss: the estimate is a conversation. Treat a challenge as an invitation to reason together.

The three most common capacity estimation mistakes

• Spending too long on arithmetic and running out of design time. Fix: time-box the estimate to about three minutes, round aggressively, and move on. The design is the point; the estimate is the bridge to it.
• Forgetting to state assumptions, so the interviewer cannot follow. Fix: say users, frequency and item size before any calculation. Without them, the number looks pulled from thin air.
• Computing a number and never using it. Fix: end every estimate with "which means we should ...". If you cannot finish that sentence, the estimate was not worth doing.

A short practice routine you can run before the interview

Pick three familiar systems: a social feed, a chat app, a photo storage service. Estimate each one in three minutes on paper, using the four steps and writing the conclusion sentence at the bottom. The repetition builds the habit of concluding.

Then record yourself narrating one estimate out loud. Play it back and check two things: did you state assumptions before computing, and did you end with a design implication? If either is missing, redo it. Finally, rehearse the challenge-and-recover move with a friend, or switch one assumption yourself and follow it through. Practising the recovery is what keeps you calm when the interviewer pushes back.

Before you walk in

The estimate is a short spoken step, not a test you can fail. State assumptions, round hard, compute in powers of ten, and always end with what the number changes. Next, set a three-minute timer and narrate one URL shortener estimate aloud, from assumptions to conclusion. If you can do that calmly, you can do it in the room.

Frequently asked questions

Do I need exact numbers, or is an order-of-magnitude estimate acceptable?

An order-of-magnitude estimate is what is usually expected. Interviewers care that your assumptions are stated and your result is used, not that the figure is precise. Rounding to powers of ten keeps you fast and makes the reasoning easy to follow. A tidy rough number with a clear conclusion beats a precise one you cannot defend.

What if I genuinely do not know a typical value, like average photo size?

Say so, pick a defensible round value, and flag it as an assumption. For example: "I'll assume a photo is about 1 MB; if it's smaller, storage drops proportionally." Naming the uncertainty and showing how the result moves with it demonstrates more judgment than pretending to know. Interviewers often accept the assumption and move on.

Should I write the estimate down or just say it out loud?

Do both where you can. A few lines on the whiteboard or shared doc give the interviewer something to follow, and speaking the steps keeps them with you. If there is no writing surface, narrate clearly and pause between steps. The spoken reasoning is what is being assessed; the writing is just support.

How does capacity estimation change for a write-heavy system like logging or metrics?

The method is the same, but the conclusion shifts. When writes dominate, you look at batching, queues, and partitioning the write path rather than caching reads. State your write rate first, derive storage growth, and say plainly that the write path is where complexity belongs. The four steps do not change; only the design move at the end does.

Practise narrating an estimate out loud before the real interview.