Module 01 · Lesson 6 of 14Free

Capacity estimation: users, storage and traffic

Level

Beginner

Topic

System design fundamentals

Reading time

14 min

At the festival sale, Kartly expects 1,000 requests a second. Its app server has 8 CPU cores. The launch checklist says “50,000 customers a day”, but that number doesn’t tell the team whether checkout will keep working.

How do you turn customers, clicks and saved orders into a useful capacity estimate?

Customers don’t arrive evenly

Capacity estimation means predicting resource demand from expected activity. It is a model with assumptions, not proof that a server can handle the load.

We stay at Kartly’s first stage: one app server and one PostgreSQL database. Start with the product targets from Functional and non-functional requirements. A useful estimate must support those targets, not just count requests.

For this lesson’s scenario, assume each daily customer generates 80 requests to Kartly’s app. This includes browsing, cart changes and checkout. It excludes image downloads, which we budget separately.

Use seconds for server capacity, days for business activity, and years for retained data. Write the unit beside every input. Otherwise, a correct multiplication can answer the wrong question.

The average explains daily volume. The peak determines the next capacity question.

Size for the busy interval

A daily average spreads the festival rush across quiet hours. Customers cannot use spare capacity from midnight when checkout freezes at sale opening.

The interval matters too. A minute containing 60,000 requests averages 1,000 requests a second. It does not prove those requests arrived evenly within that minute.

We now know how much work arrives. We still need to know how expensive that work is.

Requests have different resource costs

A request rate is not a complete capacity description. Google’s overload guidance warns that different requests can require very different resources. It recommends considering the resources consumed, not only query counts.^{1Handling OverloadAlejandro Forero Cuervo, Site Reliability Engineering, O’Reilly Media, 2016}

Use the distinction from Latency and throughput: time per request and requests per second describe different things.

For an initial calculation, assume the peak consists of requests like Kartly’s product-page example:

These are illustrative request costs, not measured limits. The database and pricing service are existing dependencies, not new components introduced by this estimate.

Server concurrency explains how waiting requests share workers. Here, the important distinction is between CPU work and elapsed time.

The database wait is not app CPU demand. It also does not reveal the database’s CPU cost.

Our estimate therefore says “the modeled app CPU demand fits”. It does not say “the system handles the sale”.

For a real request mix, calculate each request class separately, then add its demand. If checkout costs more CPU than browsing, changing their proportions changes total demand even at the same request rate.^{1Handling OverloadAlejandro Forero Cuervo, Site Reliability Engineering, O’Reilly Media, 2016}

The missing measurements are now specific: request mix, dependency capacity and behavior under load.

Bytes expose a different limit

For this scenario, assume an average app response body of 20 kB. We use decimal units throughout: one kB is 1,000 bytes; one GB is one billion bytes.

This is a payload estimate. It excludes request bodies, protocol overhead and images. Compare it with usable network throughput measured under the intended conditions, not just a connection’s advertised rate.

Now suppose each page also downloads three images. At an assumed 200 kB per image, that is 600 kB per page.

Do not multiply that by every app request. Cart updates and checkout calls are not page loads. First estimate image-bearing page views, then multiply by image bytes.

That separation prevents two mistakes: overlooking media traffic and charging every request for media it never downloads.

Storage needs the same separation between different kinds of data.

Retention turns writes into storage

Kartly takes 5,000 orders a day. For this scenario, assume each order and its line items need 2 kB of logical data.

Logical data means the estimated content before database storage overhead. PostgreSQL stores table data and indexes separately; wide values can also use additional storage. A payload estimate therefore does not equal physical disk usage.^{229.1. Determining Disk UsagePostgreSQL Global Development Group, PostgreSQL 16 Documentation, 2023}

The 7.3 GB estimate is annual growth, not a disk purchase recommendation. Existing tables, logs, temporary work and operational free space still need budgets. Backups need a separate budget too.

For comparison, Kartly’s 100,000 products would contain 60 GB of image content under our three-image assumption. That is a catalog snapshot, not annual growth.

Replace the database allowance by measuring representative tables and their indexes. PostgreSQL documents SQL functions as its recommended way to inspect disk usage.^{229.1. Determining Disk UsagePostgreSQL Global Development Group, PostgreSQL 16 Documentation, 2023}

The storage result gives us a reason to measure actual bytes. It does not yet justify splitting the database.

Uncertainty should change the next action

Suppose Kartly’s team proposes a 70% app CPU planning budget. That leaves headroom: capacity deliberately left unused in the model.

A small sensitivity check helps prioritize that test:

Each row changes one input. That makes the cause visible.

Measurements close the planning loop

Run the expected mix against representative data. Reproduce the sudden sale opening, rather than only increasing traffic slowly.

Record incoming requests, completed requests, errors and latency. Also inspect CPU, memory, waiting work and dependency limits. Resource consumption matters because equal request rates can impose different costs.^{1Handling OverloadAlejandro Forero Cuervo, Site Reliability Engineering, O’Reilly Media, 2016}

For an illustrative failure, suppose 1,000 requests arrive each second but only 800 complete. If none are rejected or abandoned, waiting work grows by 200 requests a second. Customers see increasingly delayed cart and checkout responses.

More waiting is not extra capacity. Compare arrivals with completions to detect the gap, then identify the saturated resource. The load-testing lab develops that measurement process.

Where this shows up

• Design: a URL shortener on a single server: separate frequent redirects from less frequent link creation.
• Design: an e-commerce checkout: budget expensive order work separately from browsing.

Enough capacity under normal conditions still leaves another question: what happens when a component fails? Next, Core system properties separates serving requests, preserving data and agreeing on values.

Common mistakes

• Starting from registered accounts. Use active customers and their activity for the period you are estimating.
• Treating a request rate as a benchmark. State the request mix, data size and acceptable latency alongside it.
• Counting requests as writes. A read may store nothing; an order can create several records.
• Buying exactly the calculated storage. Separate growth, existing data, working space and backups.
• Hiding uncertainty in precise numbers. Keep the arithmetic inspectable, then round the result and name the uncertain inputs.

Check your understanding

Summary