Introduction

Capacity estimation converts product expectations into approximate numbers that can guide architecture decisions.

Before selecting databases, caches, queues, partitions or server counts, a system designer should estimate:

• How many requests arrive during an average second
• How many requests arrive during peak periods
• How much traffic consists of reads and writes
• How much new data is created
• How long the data must be retained
• How much storage is required after replication and overhead
• How much data enters and leaves the system
• How much spare capacity is required for growth and failure

Capacity estimation is often called back-of-the-envelope estimation because the initial goal is not perfect precision. The goal is to create an understandable, internally consistent model that exposes the likely scale and bottlenecks.

In the System Design curriculum, QPS, storage and bandwidth estimation is Topic 1.8 and completes the System Design Process and Estimation module. The module uses a URL shortener as the practical exercise, progressing from requirements through request flows, bottlenecks and capacity estimates.

Prerequisites

Capacity Estimation Workflow

1. Define the operations being estimated.
2. List the workload assumptions and their sources.
3. Calculate daily request volume.
4. Convert daily volume to average QPS.
5. Apply a justified peak factor.
6. Separate read and write traffic.
7. Calculate logical data created per period.
8. Apply retention, replication and storage overhead.
9. Calculate ingress and egress bandwidth separately.
10. Add growth and failure headroom without double-counting.
11. Identify the assumptions that most affect the result.
12. Validate estimates through measurements and load testing.

Start with an Assumption Sheet

Estimates should begin with explicit inputs rather than hidden mental assumptions.

What Is QPS?

QPS stands for queries per second. In system design, the term is frequently used as a general estimate of requests or operations processed each second.

\[ Average\ QPS = \frac{Requests\ During\ Period} {Seconds\ During\ Period} \]

One day contains:

\[ 24 \times 60 \times 60 = 86{,}400\ seconds \]

Therefore:

\[ Average\ Daily\ QPS = \frac{Requests\ Per\ Day}{86{,}400} \]

Estimate Requests per Day

When usage is expressed through daily active users:

\[ Requests\ Per\ Day = Daily\ Active\ Users \times Requests\ Per\ User\ Per\ Day \]

Example

Assume:

• 10 million daily active users
• 20 redirect requests per user per day

\[ Redirects\ Per\ Day = 10{,}000{,}000 \times 20 \]

\[ Redirects\ Per\ Day = 200{,}000{,}000 \]

Calculate Average QPS

\[ Average\ Redirect\ QPS = \frac{200{,}000{,}000}{86{,}400} \]

\[ Average\ Redirect\ QPS \approx 2{,}315 \]

This means the synthetic workload averages approximately 2,315 redirects per second when distributed uniformly across the entire day.

Actual traffic is rarely uniform. The average is a useful baseline, not a sufficient capacity target.

Calculate Peak QPS

An initial peak estimate can apply a peak-to-average factor:

\[ Peak\ QPS = Average\ QPS \times Peak\ Factor \]

Using an illustrative peak factor of five:

\[ Peak\ Redirect\ QPS = 2{,}315 \times 5 \]

\[ Peak\ Redirect\ QPS \approx 11{,}575 \]

The peak factor should be based on historical traffic, campaign behaviour, geographic usage patterns, business events or an approved planning assumption.

The system receives 2,315 QPS.

Assuming 10 million daily active users, 20 redirects per active user per day,
86,400 seconds per day and a peak factor of 5:

Average redirect QPS ≈ 2,315
Estimated peak redirect QPS ≈ 11,575

Separate Read and Write QPS

Reads and writes often create different load patterns and architecture requirements.

Estimate them separately:

\[ Read\ QPS = Total\ QPS \times Read\ Fraction \]

\[ Write\ QPS = Total\ QPS \times Write\ Fraction \]

For a URL shortener, link creation is a write operation while redirection is primarily a read operation.

Link Creation Example

Assume each of 10 million daily active users creates an average of 0.1 links per day:

\[ New\ Links\ Per\ Day = 10{,}000{,}000 \times 0.1 = 1{,}000{,}000 \]

\[ Average\ Creation\ QPS = \frac{1{,}000{,}000}{86{,}400} \approx 11.57 \]

With the same illustrative peak factor of five:

\[ Peak\ Creation\ QPS \approx 57.87 \]

The synthetic example is strongly read-heavy:

\[ Read\ To\ Write\ Ratio = \frac{200{,}000{,}000} {1{,}000{,}000} = 200:1 \]

This ratio helps explain why the redirect path may require different scaling and caching decisions from the link-creation path.

External QPS vs Internal QPS

One public request can generate multiple internal operations.

One redirect request
        |
        +--> One cache lookup
        |
        +--> On cache miss, one database lookup
        |
        +--> One analytics event
        |
        +--> Selected observability operations

Therefore, external request QPS should not be assumed to equal:

• Database query QPS
• Cache-operation QPS
• Message-publication QPS
• Worker-processing QPS
• External-provider QPS

Cache-adjusted Database QPS

A simplified database-read estimate is:

\[ Database\ Read\ QPS = Read\ QPS \times (1 - Cache\ Hit\ Ratio) \]

If peak redirect QPS is 11,575 and the observed cache-hit ratio is 90%:

\[ Database\ Read\ QPS = 11{,}575 \times 0.10 \]

\[ Database\ Read\ QPS \approx 1{,}158 \]

This simplified estimate assumes every cache miss leads to one database read. Real request flows can include retries, duplicate misses, negative caching and additional lookups.

Storage Estimation

Storage estimation begins with the amount of logical data created and then applies retention, replication, indexing, metadata and operational overhead.

\[ Logical\ Storage = New\ Records \times Average\ Record\ Size \times Retention \]

A broader physical-storage estimate is:

\[ Physical\ Storage = Logical\ Storage \times Replication\ Factor + Indexes + Metadata + Operational\ Overhead \]

Estimate the Record Size

A URL-mapping record may contain:

These are synthetic assumptions for calculation practice. Production record size should be measured from the selected encoding and storage engine.

Daily Storage Growth

With one million new links per day and an average logical record size of 500 bytes:

\[ Daily\ Logical\ Storage = 1{,}000{,}000 \times 500\ bytes \]

\[ Daily\ Logical\ Storage = 500{,}000{,}000\ bytes \]

Using decimal units:

\[ Daily\ Logical\ Storage \approx 500\ MB \]

Annual Storage

\[ Annual\ Logical\ Storage = 500\ MB \times 365 \]

\[ Annual\ Logical\ Storage \approx 182.5\ GB \]

Retained Storage

For five years of retention:

\[ Five\ Year\ Logical\ Storage = 182.5\ GB \times 5 \]

\[ Five\ Year\ Logical\ Storage \approx 912.5\ GB \]

Apply Replication

If the approved storage design keeps three complete copies:

\[ Replicated\ Record\ Storage = 912.5\ GB \times 3 \]

\[ Replicated\ Record\ Storage \approx 2.7375\ TB \]

This number covers only the synthetic mapping-record estimate. It does not yet include indexes, backups, logs, temporary files or reserved free capacity.

Storage Components Often Missed

Logical vs Physical Storage

Compression and Deduplication

Compression and deduplication can reduce physical storage, but their effect must be measured for representative data.

If a measured compression ratio is defined as:

\[ Compression\ Ratio = \frac{Uncompressed\ Size}{Compressed\ Size} \]

Then:

\[ Compressed\ Size = \frac{Uncompressed\ Size}{Compression\ Ratio} \]

Do not apply an assumed compression benefit to already compressed images, audio or video without evidence.

Bandwidth Estimation

Bandwidth estimation calculates the rate at which data must be transmitted.

\[ Bandwidth = Operations\ Per\ Second \times Bytes\ Per\ Operation \]

Calculate the two directions independently:

• Ingress is data entering the measured boundary.
• Egress is data leaving the measured boundary.

Ingress Bandwidth

\[ Ingress\ Bandwidth = Write\ QPS \times Average\ Request\ Size \]

Suppose peak link-creation QPS is approximately 58 and the average creation request is 500 bytes:

\[ Peak\ Ingress = 58 \times 500 \]

\[ Peak\ Ingress = 29{,}000\ bytes/second \]

\[ Peak\ Ingress \approx 29\ KB/s \]

Protocol headers, encryption overhead, retries and observability traffic are not included in this simplified application-payload estimate.

Egress Bandwidth

\[ Egress\ Bandwidth = Read\ QPS \times Average\ Response\ Size \]

Suppose peak redirect QPS is approximately 11,575 and the average redirect response is 600 bytes:

\[ Peak\ Egress = 11{,}575 \times 600 \]

\[ Peak\ Egress = 6{,}945{,}000\ bytes/second \]

\[ Peak\ Egress \approx 6.945\ MB/s \]

Convert Bytes per Second to Bits per Second

Storage and payload sizes are commonly expressed in bytes, while network capacity is frequently expressed in bits per second.

\[ Bits\ Per\ Second = Bytes\ Per\ Second \times 8 \]

\[ 6.945\ MB/s \times 8 = 55.56\ Mb/s \]

Therefore, the illustrative peak application-response traffic is approximately 55.56 megabits per second before protocol, retry and safety headroom.

Network Traffic Is More Than Payload Size

A fuller estimate can include:

• Request and response headers
• Transport and encryption overhead
• Retries and retransmissions
• Replication traffic
• Service-to-service calls
• Queue and stream traffic
• Database protocol traffic
• Logs, metrics and traces
• Backup and migration traffic
• Cross-region transfer

Keep user-facing ingress and egress separate from internal network traffic so the estimate remains understandable.

Large-object Example

Bandwidth becomes especially important for images, audio, video and file downloads.

Suppose a system serves 2,000 objects per second and the average object is 2 MB:

\[ Egress = 2{,}000 \times 2\ MB \]

\[ Egress = 4{,}000\ MB/s = 4\ GB/s \]

\[ Network\ Rate = 4\ GB/s \times 8 = 32\ Gb/s \]

This type of result can motivate investigation of object storage, content delivery, regional distribution and caching, subject to the system's requirements and constraints.

Estimate Cache Capacity

A cache-capacity estimate requires the number of hot entries and the average memory consumed per entry.

\[ Cache\ Memory = Hot\ Entries \times Memory\ Per\ Entry \]

Suppose:

• Five million mappings are considered hot
• Each cached mapping consumes an estimated 700 bytes including cache overhead

\[ Cache\ Memory = 5{,}000{,}000 \times 700 \]

\[ Cache\ Memory = 3.5\ GB \]

Actual cache memory should be measured because key representation, object headers, allocator behaviour, expiration metadata and fragmentation can significantly affect per-entry memory.

Estimate Instance Count Only After Measurement

QPS alone does not determine how many application instances are required. The supported QPS per instance depends on:

• Request complexity
• CPU usage
• Memory usage
• Payload size
• Database and dependency latency
• Connection limits
• Runtime configuration
• Latency and error-rate objectives

After load testing establishes sustainable per-instance throughput:

\[ Required\ Instances = \left\lceil \frac{Peak\ QPS} {Sustainable\ QPS\ Per\ Instance} \right\rceil \]

If measured sustainable throughput is 1,000 QPS per instance:

\[ Base\ Instance\ Count = \left\lceil \frac{11{,}575}{1{,}000} \right\rceil = 12 \]

This is only the base count before accounting for target utilization, maintenance, deployment and failure headroom.

Headroom

Headroom is spare capacity reserved for variability, growth, maintenance and failure.

One target-utilization approach is:

\[ Provisioned\ Capacity = \frac{Required\ Peak\ Capacity} {Target\ Utilization} \]

If required peak capacity is 11,575 QPS and target utilization is 70%:

\[ Provisioned\ Capacity = \frac{11{,}575}{0.70} \]

\[ Provisioned\ Capacity \approx 16{,}536\ QPS \]

If one tested instance sustains 1,000 QPS:

\[ Provisioned\ Instances = \left\lceil \frac{16{,}536}{1{,}000} \right\rceil = 17 \]

Avoid Double-counting

Peak factor, growth allowance, failure reserve and utilization target are different concepts. Define each one and avoid applying two factors for the same uncertainty.

Capacity During Failure

Availability requirements can require the remaining healthy components to serve the workload after a failure.

For \(N\) identical instances with one-instance failure tolerance:

\[ Remaining\ Capacity = (N - 1) \times Sustainable\ Capacity\ Per\ Instance \]

Verify:

\[ Remaining\ Capacity \ge Required\ Failure\ Workload \]

Merely running multiple instances does not prove that adequate capacity remains after failure.

Estimate Queue Backlog

If asynchronous work arrives faster than workers complete it:

\[ Backlog\ Growth\ Per\ Second = Arrival\ Rate - Completion\ Rate \]

Suppose notification work arrives at 5,000 messages per second while workers complete 4,200:

\[ Backlog\ Growth = 5{,}000 - 4{,}200 = 800\ messages/second \]

After ten minutes:

\[ Backlog = 800 \times 600 = 480{,}000\ messages \]

Drain Time

If arrivals later return to 3,000 messages per second while workers still complete 4,200:

\[ Spare\ Processing\ Rate = 4{,}200 - 3{,}000 = 1{,}200\ messages/second \]

\[ Drain\ Time = \frac{480{,}000}{1{,}200} = 400\ seconds \]

\[ Drain\ Time \approx 6.67\ minutes \]

The estimate assumes rates remain stable and ignores retries, failures and priority classes.

Model Growth Over Time

If workload grows at an expected annual rate \(g\):

\[ Future\ Load = Current\ Load \times (1 + g)^n \]

Where \(n\) is the number of years.

For example, with a current peak of 10,000 QPS and an illustrative annual growth assumption of 30%:

\[ Year\ 1 = 10{,}000 \times 1.30 = 13{,}000 \]

\[ Year\ 2 = 10{,}000 \times 1.30^2 = 16{,}900 \]

Growth assumptions should be reviewed periodically because actual usage can differ significantly from an early forecast.

Sensitivity Analysis

Sensitivity analysis identifies which assumptions most strongly influence the design.

When the design changes dramatically after a small assumption change, that assumption deserves validation or a flexible architecture.

Complete URL Shortener Estimate

Synthetic Inputs

Calculated Outputs

Architecture Implications

1. The illustrative workload is heavily read-oriented.
2. The redirect path needs substantially more request capacity than the creation path.
3. Caching can materially reduce authoritative-store read traffic when locality exists.
4. The required mapping storage is manageable in the synthetic example, but indexes and operational copies still matter.
5. Redirect bandwidth is larger than creation-request ingress because redirects dominate the workload.
6. Analytics events can create a separate high-volume storage and processing requirement.
7. Instance count still requires measured sustainable throughput per instance.
8. Failure and growth capacity must be added according to approved objectives.

Estimation Worksheet Template

Common Estimation Mistakes

Capacity Review Checklist

Practice Exercise

Estimate capacity for a notification platform using the following synthetic assumptions:

Tasks

1. Calculate notifications per day.
2. Calculate average acceptance QPS.
3. Calculate estimated peak QPS.
4. Calculate daily logical status storage.
5. Calculate 90-day logical status storage.
6. Apply the replication factor.
7. Calculate peak provider-request bandwidth.
8. Calculate peak provider-response bandwidth.
9. Identify storage components missing from the basic calculation.
10. Explain how provider rate limits could become the bottleneck.

Model Solution

\[ Notifications\ Per\ Day = 500{,}000 \times 40 = 20{,}000{,}000 \]

\[ Average\ QPS = \frac{20{,}000{,}000}{86{,}400} \approx 231.48 \]

\[ Peak\ QPS = 231.48 \times 4 \approx 925.93 \]

Using decimal units and 1 KB as 1,000 bytes:

\[ Daily\ Logical\ Storage = 20{,}000{,}000 \times 1{,}000 \]

\[ Daily\ Logical\ Storage = 20\ GB \]

\[ 90\ Day\ Logical\ Storage = 20\ GB \times 90 = 1.8\ TB \]

\[ Replicated\ Storage = 1.8\ TB \times 3 = 5.4\ TB \]

Peak provider-request traffic:

\[ 925.93 \times 2{,}000 \approx 1.852\ MB/s \]

\[ 1.852\ MB/s \times 8 \approx 14.81\ Mb/s \]

Peak provider-response traffic:

\[ 925.93 \times 500 \approx 0.463\ MB/s \]

\[ 0.463\ MB/s \times 8 \approx 3.70\ Mb/s \]

The calculation does not yet include indexes, event queues, retry traffic, message metadata, audit records, backups, logs, protocol overhead or free operating capacity.

Frequently Asked Questions