Capacity Estimation in System Design

You are planning a service where people upload notes and read them later. Before choosing servers, ask how many people use it, how often they make requests and how much data each request moves. Those assumptions turn a vague idea into numbers you can discuss and test.

Capacity estimation is an initial plan for the work and resources a system may need. An estimate helps you spot expensive parts and compare options. It does not prove that a particular machine or database can handle the workload.

Suppose 100,000 daily users each make 10 requests. That is 1,000,000 requests per day. Dividing by the 86,400 seconds in a day gives about 11.6 requests per second on average. RPS is short for requests per second.

Average traffic hides busy periods. If your busiest interval is five times the daily average, plan for about 57.9 RPS during that interval. Five is an assumption here; real peak demand comes from observed traffic or a clearly stated launch scenario.

A 20 kB response at 57.9 RPS moves about 1.16 MB of response payload per second. This lesson uses decimal units: 1 kB = 1,000 bytes, 1 MB = 1,000,000 bytes and 1 GB = 1,000,000,000 bytes. Multiply MB/s by eight for payload Mbit/s. Protocol overhead, incoming data and retries are additional.

Adjust daily requests, the peak multiplier, response size and retention. Read each result with its unit. Doubling response size changes payload bandwidth, but does not by itself double the request count.

For storage, this model assumes 20% of requests create one new 1 kB record, retained for the selected number of days, with three full copies. That is an assumed append-only workload: it excludes indexes, backups, logs, compression and storage-engine overhead. Retention is a steady-state window, not an instant allocation.

The server count uses an illustrative measured limit of 100 RPS per server at acceptable latency and errors, operated at a planning budget of 70 RPS. The extra server allows loss of one identical server if routing and dependencies can still support the load. These are example assumptions, not hardware specifications.

Headroom means capacity left available beyond normal demand. A system running close to its limit can become slow when traffic rises, a server fails or a deployment temporarily reduces available machines. New capacity also takes time to start and become ready.

If peak demand is 200 RPS and your chosen operating budget is 70 RPS per server, three servers cover demand in this simplified model. A fourth preserves that three-server budget after one server fails. This arithmetic assumes work can be distributed and the database, network and other shared resources can support it.

A single popular record, a serial task or a shared database bottleneck can prevent capacity from scaling evenly. Test the failure scenario as well as the healthy one. Spare servers are useful only when the rest of the system can use them.

Reading the same record many times increases request traffic without necessarily creating new stored records. Uploading one large video may add far more storage than thousands of small reads. Estimate each request type separately when their costs differ.

For new records, a starting equation is records per day × bytes per record × retention days. Apply copy counts separately, then account for indexes, backups, logs and product overhead. Do not assume three copies in every service: the storage product and recovery requirements determine the actual layout.

Check how deletion works, how long backups retain old data and whether the design keeps growing without a retention limit. Capacity is also about recovery: enough space to restore data or rebuild a copy may be needed during an incident.

Start with a small representative workload: realistic payloads, read/write mix, authentication and database calls. Measure successful throughput, latency, errors and the resource that fills up first. An empty response benchmark does not describe an application that writes large records.

Grafana k6 documents load-test types for normal load, stress, spikes and sustained runs. The open-source tool can be self-hosted; hosted offerings have separate commercial terms. Google’s monitoring guidance connects traffic and latency with errors and resource saturation. Official sources checked 6 October 2026.

Use measurements to replace the calculator’s assumptions. Compare compute, storage and transfer costs separately. There is no universal RPS figure for a software name or instance size: configuration, request work and dependencies affect the result.

Start from activity, convert units carefully and separate average demand from busy intervals. Estimate payload transfer and retained data with different equations. Include headroom and a clear failure scenario.

Use the estimate to guide experiments, then replace guesses with measurements. A plan becomes stronger when another person can see its assumptions, change them and understand which resource grows.