Free System Design Capacity Estimator: QPS, Storage, Bandwidth, and Headroom

This free system design capacity estimator converts a small set of workload assumptions into four checkable outputs: average and peak QPS, retained storage, ingress and egress bandwidth, and provisioned capacity with headroom. The formula-driven workbook recalculates as you edit its yellow input cells. It is an interview and early-design tool, not a cloud sizing quote, and every result remains attached to the assumption that produced it.

Open the free capacity estimator workbook, then enter daily active users, actions per user, read/write mix, peak factor, payload sizes, retention, growth, replication, and target utilization. It calculates the outputs live, flags invalid combinations, and keeps the equation map visible. Use the results to decide where caching, partitioning, queues, object storage, a CDN, or load testing matter.

What this estimator does and does not do

The estimator gives an internally consistent first model. Its Estimator sheet keeps editable assumptions beside live outputs, while Formula Guide explains the units and system boundaries. It helps you answer: How many requests arrive each second? How much data accumulates? Which network direction is larger? How much capacity remains during growth or a failure?

It does not tell you how many servers to buy without a measured per-instance throughput. Two endpoints with the same QPS can have radically different CPU, memory, storage I/O, dependency, and latency costs. The arithmetic should narrow the design conversation; a load test must connect workload units to real resources.

For a deeper interview framework covering bottlenecks, failure capacity, and validation, see Capacity Planning Interview Questions for Senior Engineers.

Step 1: Fill in the input sheet

Open the workbook's Estimator sheet and replace the yellow sample values. Use decimal units: 1 KB = 1,000 bytes, 1 GB = 10^9 bytes, and 1 TB = 10^12 bytes. If a storage system reports KiB, GiB, or TiB, keep those binary units labeled and do not mix them mid-calculation.

Input	Symbol	Example	What to clarify
Daily active users	DAU	5,000,000	Unique active users, not registered users
Reads per active user per day	R	20	Edge requests before cache-hit adjustments
Writes per active user per day	W	0.2	Durable write events, not every internal call
Peak-to-average factor	P	4	Derived from traffic history when available
Forecast growth factor	G	1.5	End-of-horizon demand divided by current demand
Average read response	Br	8 KB	Bytes sent from the modeled boundary
Average write request	Bw	2 KB	Bytes entering the modeled boundary
Retention	D	365 days	Online plus required archive period
Index and metadata overhead	O	25%	Excludes replication unless stated
Replication factor	N	3	Use the system's actual durability scheme
Target storage fullness	Fs	80%	Provisioned bytes allowed to be occupied
Target network utilization	Fn	70%	Sustained utilization target, not a universal rule

Define the boundary before calculating. Edge QPS, service QPS, database operations per second, and queue events per second are not interchangeable. One API read might fan out to three services and ten storage reads. Add explicit fanout, cache-hit, retry, or write-amplification factors when they change the component you are sizing.

Step 2: Estimate average and peak QPS

There are 86,400 seconds in a day. For a uniformly distributed workload:

average_read_qps = DAU x reads_per_user_per_day / 86,400

average_write_qps = DAU x writes_per_user_per_day / 86,400

Average QPS is a baseline, not a capacity target. Apply a peak factor to represent daily concentration, launch events, regional skew, or bursts:

current_peak_qps = average_qps x peak_factor

For a planning horizon, apply the forecast separately:

forecast_peak_qps = current_peak_qps x growth_factor

Keep reads and writes separate. A read-heavy product may have modest durable ingestion but enormous origin egress. A write-heavy telemetry system may have lower response bandwidth while stressing partitions, queues, and storage compaction.

If you already have production data, replace the guessed peak factor with measured sustained peaks and burst windows. A five-second burst and a two-hour peak may require different controls even if their maximum QPS is identical.

Step 3: Estimate retained storage

Start with new logical data created per day:

raw_bytes_per_day = writes_per_day x stored_bytes_per_write

Then account for retention and growth. If demand grows linearly from today's rate to an end-of-horizon factor G, the average growth factor over that horizon is:

average_growth_factor = (1 + G) / 2

raw_retained_bytes = raw_bytes_per_day x retention_days x average_growth_factor

This linear model is only a stated approximation. Replace it with a monthly forecast when growth is seasonal, stepwise, or driven by launches.

Add logical overhead before durability copies:

logical_storage = raw_retained_bytes x (1 + index_and_metadata_overhead)

physical_storage = logical_storage x replication_factor

Finally, divide by target fullness rather than simply adding the unused percentage:

provisioned_storage = physical_storage / target_storage_fullness

At 80% target fullness, divide by 0.8. This leaves 20% of provisioned space free. Multiplying by 1.2 would leave only 16.7% of the final capacity free, a common denominator mistake.

List anything omitted: object versions, tombstones, WAL or change logs, backups, cross-region copies, temporary compaction space, cache copies, thumbnails, embeddings, and analytics replicas. Replication factor 3 is not interchangeable with an erasure-coding overhead ratio.

Step 4: Estimate ingress and egress bandwidth

Network throughput uses bits per second, while payload size is usually measured in bytes. Convert explicitly:

ingress_bps = forecast_peak_write_qps x average_write_bytes x 8

egress_bps = forecast_peak_read_qps x average_response_bytes x 8

Then apply the target utilization:

provisioned_bandwidth = expected_bandwidth / target_network_utilization

This is application payload bandwidth at the chosen boundary. Protocol headers, TLS, retries, replication traffic, service-to-service calls, and cache misses can increase network demand. A CDN may reduce origin egress without changing client-visible traffic. Compression may reduce bytes while adding CPU cost. State which effects are inside your number.

Step 5: Model headroom without double-counting

Headroom is not one magic percentage. Separate four reasons for spare capacity:

• Forecast uncertainty: actual adoption may exceed the demand model.
• Scaling delay: instances, shards, or storage may take time to become useful.
• Burst tolerance: short spikes can exceed the sustained peak.
• Failure capacity: the remaining fleet must serve traffic after a node, zone, or dependency loss.

A target utilization expresses operating headroom. If forecast demand is 100 units and target utilization is 70%, provision 100 / 0.70 = 142.9 units. That means 30% of provisioned capacity is free, or capacity is 42.9% above demand. Those two percentages use different denominators.

Do not add another arbitrary 30% unless it covers a separate risk. Instead, test the failure case directly: after removing the largest required fault domain, can the remaining capacity still meet the latency and error targets? Autoscaling does not replace failure capacity when scale-up is slower than the outage or burst.

Worked example: 5 million DAU

Assume 5 million DAU, 20 reads and 0.2 writes per user each day, a 4x peak factor, and 50% end-of-year growth. Average payloads are 8 KB per read response and 2 KB per write. Retain writes for 365 days, add 25% for indexes and metadata, keep three replicas, target 80% storage fullness, and target 70% network utilization.

Output	Calculation	Result
Average read QPS	5M x 20 / 86,400	1,157 QPS
Average write QPS	5M x 0.2 / 86,400	11.6 QPS
Current peak read QPS	1,157 x 4	4,630 QPS
Forecast peak read QPS	4,630 x 1.5	6,944 QPS
Forecast peak write QPS	11.6 x 4 x 1.5	69.4 QPS
Forecast application egress	6,944 x 8,000 x 8	444 Mbps
Provisioned egress at 70%	444 / 0.70	635 Mbps
Raw new data today	1M writes x 2 KB	2 GB/day
Retained raw data with linear growth	2 GB x 365 x 1.25	912.5 GB
Provisioned storage	912.5 GB x 1.25 x 3 / 0.80	4.28 TB

Forecast application ingress is only about 1.11 Mbps, or 1.59 Mbps provisioned at 70%. That contrast is useful: the edge is dominated by read egress, while the write path remains important for durability and retained storage.

The result should change the design discussion. An origin cache or CDN could reduce service and database read load. The storage plan is far larger than the raw 730 GB produced at today's rate because growth, overhead, replication, and free space are visible. None of these numbers yet yields a server count.

Convert QPS into instances only after a load test

Measure sustainable throughput per instance while the request mix, payloads, dependencies, latency percentile, and error rate match the design target. Then use:

instances = ceil(forecast_peak_qps / sustainable_qps_per_instance)

If the test reports a maximum rather than a safe operating rate, first multiply that maximum by the chosen target utilization. Do not apply utilization twice. Then add topology requirements separately: minimum replicas, zone distribution, shard ownership, and the largest failure you must tolerate.

CPU may be the first bottleneck, but it may not be. Inspect memory, connection pools, queues, storage IOPS, cache hit rate, database saturation, network, and downstream quotas. Google SRE guidance specifically emphasizes correlating raw resources to service capacity through regular load testing rather than trusting an old machine-to-QPS ratio.

Common estimator mistakes

The most damaging errors are usually unit or boundary errors, not arithmetic difficulty:

• Dividing daily requests by 3,600 instead of 86,400.
• Designing for average QPS and mentioning peak traffic only afterward.
• Mixing KB with KiB, or bytes per second with bits per second.
• Counting replication inside overhead and multiplying by it again.
• Treating storage fullness as x 1.2 instead of / 0.8.
• Applying the client request rate directly to every backend component.
• Assuming autoscaling is instantaneous and unlimited.
• Converting QPS to servers using a guessed throughput number.

Keep a short assumption ledger beside the arithmetic. When the interviewer changes one input, update only the dependent calculations and explain which architecture choice changes.

Frequently asked questions

What is QPS in system design?

QPS means queries or requests per second at a defined boundary. Always name that boundary: client edge, API service, database, cache, or queue. Fanout, retries, and cache hits make their rates different.

Should I use average or peak QPS in an interview?

Calculate average QPS to show the baseline, then design around a stated sustained peak, burst, growth horizon, and failure condition. Use measured traffic distributions when available; otherwise label the peak factor as an assumption.

How much headroom should a system have?

There is no universal percentage. Choose target utilization based on scaling lead time, workload variance, forecast error, cost, and required failure tolerance. Validate that the remaining system can meet its objectives after the largest planned failure.

Does replication count toward storage capacity?

Yes. Raw logical bytes must be expanded by indexes and metadata, then by the actual replication or erasure-coding overhead. Backups, logs, versions, and compaction space may require additional separate capacity.

Why estimate bandwidth separately from QPS?

QPS counts operations, not bytes. A service returning 1 MB objects at 1,000 QPS moves far more data than one returning 1 KB objects at the same rate. Network direction, cache boundary, compression, and protocol overhead also affect the result.

Final check

A useful capacity estimate has a visible chain: assumptions -> current average -> sustained peak -> forecast demand -> storage and network demand -> target utilization -> failure validation. Keep units attached, avoid double-counting, and connect every number to a design choice. The estimate is complete when another engineer can change one assumption and reproduce the result.

Sources and Further Reading

• Google SRE: Demand Forecasting and Capacity Planning
• Google SRE: Production Services Best Practices - Capacity Planning
• Google SRE: Intent-Based Capacity Planning
• Microsoft Azure Well-Architected Framework: Capacity Planning
• Google Cloud Well-Architected Framework: Optimize Resource Usage

Research note: Sources were checked on August 28, 2026. The formulas are transparent planning approximations, not vendor limits or pricing guarantees. Production capacity must be validated with representative telemetry, load tests, quotas, and failure drills.