How to Estimate Capacity Without Making Numbers Up

The problem

A lot of people treat capacity estimation as if it were a math test.

The result is predictable:

• the person gets nervous
• tries to hit a beautiful number
• gets tangled in calculations they did not even need

In interviews, that is not the point.

The interviewer does not want to see whether you can do long mental arithmetic.

They want to see whether you know how to:

• choose which numbers matter
• reach an order of magnitude quickly
• use that order of magnitude to make architecture decisions

Mental model

A good estimate is traceable.

Which means another person can look at your math and understand where each number came from.

In practice, three questions are usually enough to start:

1. how many active users do I have per day?
2. how many important actions does each user perform?
3. how heavy is each record or response?

From that, you usually derive:

• requests per second
• write volume
• read volume
• storage per day, month, and year
• approximate network traffic

If you want a simple sentence:

Capacity estimation is not about discovering the true number. It is about discovering the size of the problem early enough not to design architecture in the dark.

Breaking the problem down

Start with QPS

QPS means how many requests per second the system receives.

A simple way to get there is:

1. start with actions per day
2. divide by 86,400, the number of seconds in a day
3. apply a peak factor, because real traffic does not arrive evenly distributed

Example:

• 10 million daily active users
• each one creates 2 links per day

That gives 20 million creations per day.

Now:

• 20,000,000 / 86,400 ~= 231

The average write rate is close to 231 writes/s.

If you assume a 5x peak, you get something close to 1,150 writes/s.

Then calculate storage

Storage is usually the simplest calculation and one of the most useful.

You need to know:

• how many new records enter per day
• how much each record weighs
• how long the data will be kept

Suppose:

• 20 million links per day
• 600 bytes per record

Calculation:

• 20,000,000 x 600 bytes = 12,000,000,000 bytes

In other words, something close to 12 GB/day.

In one year:

• 12 GB x 365 ~= 4.3 TB/year

That already answers a lot.

You do not need accounting obsession to notice whether you are dealing with comfortable gigabytes or terabytes that need more care.

Then think about bandwidth

Bandwidth is the volume of data traveling over the network.

The mental math is similar:

• how many responses per second
• how much each response weighs

If the system handles 1 billion redirects per day and each redirect costs around 1 KB, you are already talking about something like 1 TB/day on the read path.

This calculation does not need to be perfect to be useful.

It can already justify:

• cache
• edge
• small responses
• analytics outside the critical path

Peak matters more than average

Average helps with basic intuition.

But systems usually break at peak, not at average.

That is why a simple sentence often makes the answer much stronger:

I will work with both average and peak, because architecture suffers at peak.

The exact factor does not need to be sacred.

It only needs to be defensible.

If you explain where the multiplier came from, even approximately, the estimate already sounds mature.

Stop when the estimate already changed the decision

This part matters because it separates maturity from whiteboard performance.

If the estimate already showed you that:

• reads dominate writes
• data volume grows quickly
• the critical path cannot carry extra processing

then it already did its job.

Continuing to refine only to look careful usually wastes time.

In interviews, too much calculation without a change in decision starts to work against you.

Simple example

Let’s build a full estimate for a URL shortener.

Assume:

• 10 million daily active users
• each user creates 2 short links per day
• each link receives 50 redirects per day on average
• each mapping weighs 600 bytes
• each redirect transfers 1 KB
• peak factor of 5x

Writes:

• 10M x 2 = 20M creations/day
• 20M / 86,400 ~= 231 writes/s
• peak ~1,150 writes/s

Reads:

• 20M links x 50 redirects = 1B redirects/day
• 1B / 86,400 ~= 11,574 reads/s
• peak ~57,870 reads/s

Storage:

• 20M x 600 bytes = 12 GB/day
• 12 GB x 365 ~= 4.3 TB/year

Bandwidth:

• 1B x 1 KB = ~1 TB/day

Just with that, you can already defend:

• reads dominate writes
• cache on the redirect path makes sense
• persistence grows meaningfully over time
• heavy analytics should not delay the main redirect path

Common mistakes

• Trying to get everything right with fake precision.
• Forgetting peak and looking only at average.
• Mixing requests per day with requests per second without converting the unit.
• Choosing arbitrary numbers without declaring assumptions.
• Continuing to refine after the architecture is already clear.

How a senior thinks

People with more experience do not use estimation to perform.

They use it to reduce risk early.

The tone is usually this:

I will do an order-of-magnitude estimate, separate average from peak, and use that to decide what really needs to scale.

That posture shows judgment.

You are not trying to impress with math.

You are trying to size the system enough to make a defensible decision.

That is the core point: estimation exists to reduce blindness, not to perform precision.

What the interviewer wants to see

In system design, capacity estimation reveals maturity quickly.

Because it shows whether you:

• choose the right numbers
• convert units without getting lost
• distinguish average from peak
• use the calculation to justify architecture

The best estimate is not the most elegant one. It is the one that makes the next decision more obvious.

An approximate number with clear reasoning is worth more than invented precision that pretends to be certainty.