System Design Day 2: Capacity Estimation

Capacity Estimation: Turn Users into Traffic, Storage, and Bandwidth

Learning outcome: By the end of Day 2, you will be able to turn a user count into an assumption-based estimate of average requests per second, peak requests per second, storage growth, and outbound bandwidth.

This lesson is part of System Design in 30 Days. Capacity estimation comes before component selection because a design for tens of requests per second is different from a design for tens of thousands.

The mental model: traffic, storage, bandwidth

A user count is not a capacity requirement. “One million users” could describe registered accounts, monthly active users, daily active users, or concurrent users. Each interpretation creates a different load.

Start with three questions:

1. Traffic: How many operations arrive per second, on average and at peak?

2. Storage: How many bytes are added per day, and how long are they retained?

3. Bandwidth: How many bytes move through the network per second?

Write assumptions before equations. Prefer a reasonable range over false precision, and keep units visible so mistakes are easier to catch.

Worked example: a one-million-user app

Imagine a photo-enabled consumer app with one million registered users. We will use a deliberately small set of assumptions:

These are teaching assumptions, not production measurements. A real design should replace them with analytics, load tests, observed percentiles, product forecasts, and a safety margin.

1. Estimate traffic

First calculate daily active users:

1,000,000 users x 10% = 100,000 daily active users

Then calculate daily requests:

100,000 active users x 20 requests/user/day
= 2,000,000 requests/day

There are 86,400 seconds in a day:

2,000,000 requests/day / 86,400 seconds/day
= 23.1 requests/second
≈ 23 average RPS

Average load hides bursts. If the expected peak is five times the average:

23.1 average RPS x 5
= 115.5 peak RPS
≈ 120 peak RPS

The rounded figure is intentional. At this stage, “about 120 RPS” is more honest than pretending the system will peak at exactly 115.5 RPS.

2. Estimate storage growth

Suppose 10,000 users upload one 2 MB image each day:

10,000 images/day x 2 MB/image
= 20,000 MB/day
≈ 20 GB/day

For one year:

20 GB/day x 365 days
= 7,300 GB/year
≈ 7.3 TB/year

That estimate covers only the original image bytes. A production storage plan might also include thumbnails, multiple resolutions, metadata, replication, backups, indexes, temporary files, and retention or deletion policies. Those multipliers must be stated separately rather than hidden inside the base estimate.

3. Estimate outbound bandwidth

At the estimated peak of 120 RPS, assume the average response is 50 KB:

120 requests/second x 50 KB/request
= 6,000 KB/second
≈ 6 MB/second

Network capacity is commonly discussed in bits per second. With eight bits per byte:

6 MB/second x 8
≈ 48 megabits/second
= 48 Mbps

This is a simplified application-payload estimate. Protocol overhead, retries, encryption overhead, cache hit rates, regional distribution, uploads, and response-size percentiles can all change real network usage.

What the estimates tell you

The numbers do not automatically select an architecture. They constrain the conversation:

• About 120 peak RPS is a traffic target for initial load testing and capacity planning.

• About 20 GB/day reveals that retention, image processing, and object-storage strategy matter.

• About 48 Mbps provides a baseline for outbound network planning.

• A five-times peak factor reminds the team not to design only for the daily average.

Cloud guidance recommends monitoring demand and workload utilization rather than guessing capacity indefinitely. Forecasts and percentiles help refine the model after real usage exists.

Try this today

Keep every assumption unchanged except peak traffic. If peak RPS doubles from 120 to 240 while average response size stays at 50 KB, what happens to outbound bandwidth?

240 requests/second x 50 KB/request
= 12,000 KB/second
≈ 12 MB/second

12 MB/second x 8
≈ 96 Mbps

Answer: outbound bandwidth doubles from about 48 Mbps to about 96 Mbps because bandwidth is directly proportional to RPS when payload size is fixed.

A completed estimate you can copy

Registered users: 1,000,000
DAU assumption: 10% = 100,000 DAU
Requests per DAU per day: 20
Daily requests: 2,000,000
Average traffic: 23 RPS
Peak factor: 5x
Peak traffic: approximately 120 RPS

Daily uploaders: 10,000
Average image: 2 MB
Storage growth: approximately 20 GB/day
Annual base growth: approximately 7.3 TB/year

Peak response rate: 120 RPS
Average response payload: 50 KB
Outbound bandwidth: approximately 48 Mbps

Open questions: replication factor, backups, thumbnails,
retention, cache hit rate, regional peaks, growth forecast.

Common mistakes

Treating registered users as concurrent users

Only a fraction of registered users may be active on a given day, and only a fraction of daily active users are active in the same second.

Designing only for the average

Average RPS smooths away bursts. State a peak factor or use observed peak percentiles when available.

Mixing bytes and bits

Storage sizes are often written in bytes, while network rates are usually written in bits per second. Show the conversion.

Hiding multipliers

Replication, backups, thumbnails, retries, and protocol overhead are real, but each deserves its own visible assumption.

Reporting precise answers from uncertain inputs

If inputs are rough, round the result and communicate a range. Capacity estimates guide decisions; they are not promises.

Knowledge check

1. Why is “one million users” insufficient for estimating RPS?

2. What is the difference between average RPS and peak RPS?

3. If image size doubles and upload count stays fixed, what happens to daily storage growth?

4. If response size halves and peak RPS stays fixed, what happens to outbound bandwidth?

Answers

1. It does not specify how many are active, how often they act, or how activity is distributed over time.

2. Average RPS spreads daily work across the whole day; peak RPS estimates the busiest period.

3. Daily storage growth doubles.

4. Outbound bandwidth halves.

Continue learning

Capacity-estimation questions are common in system design interviews because they reveal whether assumptions, units, peaks, and trade-offs are made explicit. Explore Mastering the System Design Interview on Korshub for deeper interview-focused practice. Course availability and terms may change; check the course page for current details.

Series navigation

• Previous: Day 1 - Load Balancing

• Roadmap: System Design in 30 Days

• Next published lesson: add the Day 3 link here after publication; do not link an unpublished URL.

Primary references

• AWS Well-Architected: plan and provision capacity for predictable workload usage

• AWS Well-Architected reliability design principles

• Google Cloud Capacity Planner overview

• Google Cloud storage strategy guidance