Estimating Scale and Capacity Planning

System design decisions depend heavily on scale. An architecture serving 100 requests per second can look very different from one handling 100,000 requests per second, billions of stored objects, or millions of persistent connections.

Scale estimation converts product assumptions into approximate engineering numbers: requests per second, storage growth, bandwidth, concurrent connections, cache size, and processing capacity. Capacity planning then determines how much infrastructure is required to support that workload while preserving enough headroom for traffic spikes and failures.

In a system design interview, the objective is not mathematical precision. The objective is to establish the correct order of magnitude and use those numbers to justify architectural decisions.

Table of Contents

• Why Scale Estimation Matters
• Estimating Traffic and Requests per Second
• Estimating Storage Requirements
• Estimating Network Bandwidth
• Estimating Concurrent Connections
• Capacity Planning and Headroom
• Production Design Example
• Common Mistakes
• Interview Checklist
• Conclusion
• Key Takeaway
• More Articles to Read

Why Scale Estimation Matters

Without scale estimates, architecture decisions become guesses.

Consider a service storing user-generated images. The requirement might simply say:

Users can upload and view images.

That statement does not reveal whether the system needs one application server and a few gigabytes of storage or a globally distributed object-storage architecture containing petabytes of data.

A few assumptions immediately make the problem more concrete:

Daily active users:       20 million
Uploads per user/day:     2
Average image size:       3 MB
Image views/user/day:     50

From these numbers:

Uploads/day:
20M × 2
= 40M uploads/day

Image views/day:
20M × 50
= 1B views/day

New storage/day:
40M × 3 MB
= 120 TB/day

The system is clearly read-heavy and storage-intensive. That observation immediately suggests several architectural concerns:

• object storage rather than storing binary files in application servers;
• CDN or caching for frequently viewed content;
• large long-term storage growth;
• substantial outbound network traffic;
• different scaling requirements for metadata and image data.

Estimation therefore connects product requirements to architecture:

Product Assumptions
        |
        v
Traffic / Storage / Bandwidth
        |
        v
Likely Bottlenecks
        |
        v
Architecture Decisions

Scale estimates should appear early in a system design discussion, after the main requirements are understood but before the architecture becomes too detailed. For the broader interview process, see System Design Interviews Explained: What Companies Actually Expect.

Estimating Traffic and Requests per Second

Requests per second, commonly abbreviated as RPS or QPS, are among the most useful system design estimates.

The basic calculation is:

Average RPS =
requests per day / seconds per day

Seconds per day:
24 × 60 × 60 = 86,400

For quick interview calculations, 86,400 can often be approximated as 100,000 when exact precision does not affect the conclusion.

Suppose a notification service has 10 million daily active users and each user generates five notification-producing events per day:

Events/day:
10,000,000 × 5
= 50,000,000

Average events/second:
50,000,000 / 86,400
≈ 579 events/second

Average traffic rarely represents production peaks. If peak traffic is estimated at five times average:

Peak:
579 × 5
≈ 2,900 events/second

That is a much more useful number for capacity planning.

Read and Write Ratios

Reads and writes should often be estimated separately because they create different bottlenecks.

Suppose a URL shortener receives:

New URLs created/day:     10 million
Redirects/day:             1 billion

Average write traffic:

10,000,000 / 86,400
≈ 116 writes/second

Average read traffic:

1,000,000,000 / 86,400
≈ 11,600 reads/second

The read-to-write ratio is approximately:

1,000,000,000 / 10,000,000
= 100:1

This immediately suggests that read optimization deserves more attention than write throughput. Caching popular URL mappings could substantially reduce database traffic.

This estimation pattern becomes important in the practical design covered in Designing a URL Shortener.

Peak vs Average Traffic

A common mistake is sizing the architecture for average traffic.

Average traffic: 10,000 RPS
Peak multiplier: 4×

Peak traffic: 40,000 RPS

Real traffic is rarely distributed evenly throughout the day. Product launches, major events, scheduled jobs, push notifications, time zones, and retry storms can create sharp spikes.

The peak multiplier should be stated as an assumption when actual traffic data is unavailable:

Assumption:
Peak traffic is approximately 3× average traffic.

The interviewer can then adjust the assumption if another workload model is intended.

Estimating Storage Requirements

Storage estimation begins with three questions:

1. How many records or objects are created?
2. How large is each one?
3. How long must they be retained?

Suppose a chat system generates 500 million messages per day with an average stored message size of 1 KB.

Daily storage:
500M × 1 KB
≈ 500 GB/day

Annual storage:
500 GB × 365
≈ 182.5 TB/year

Five years:
≈ 912.5 TB

This is only the raw payload estimate. Real storage may also include:

• database indexes;
• replicas;
• metadata;
• backups;
• transaction logs;
• temporary copies;
• storage-engine overhead.

If the database keeps three copies of the data for redundancy:

Raw data:
≈ 913 TB

Replication factor:
3

Replicated data:
≈ 2.74 PB

This does not mean the final storage requirement is exactly 2.74 PB. It establishes that the system operates at petabyte rather than terabyte scale, which is the useful architectural conclusion.

Separate Metadata from Large Objects

Large files often need separate estimation from metadata.

Consider a file storage service:

File metadata:
- file_id
- owner_id
- filename
- size
- checksum
- object_key
- created_at

Actual file:
10 KB - multiple GB

Storing both through the same database access path is usually unnecessary.

                  File Service
                  /          \
                 v            v
         Metadata Database  Object Storage
         small structured   large binary
         records            objects

Separate calculations help reveal that the metadata database may contain billions of small records while object storage contains petabytes of binary data.

Estimating Network Bandwidth

High request volume does not necessarily imply high bandwidth, and low request volume does not necessarily imply low bandwidth. Payload size matters.

A useful approximation is:

Bandwidth =
requests/second × average payload size

Suppose an image service serves 20,000 images per second with an average response size of 500 KB:

20,000 × 500 KB
= 10,000,000 KB/s
≈ 10 GB/s

Converting to bits:

10 GB/s × 8
≈ 80 Gbit/s

This is enough traffic that direct delivery from application servers would be inefficient and expensive. A CDN becomes an important architectural component.

Uploads and downloads should also be calculated separately:

The table reveals that request count alone would give the wrong impression. Metadata produces the most requests, while binary content dominates network capacity.

Estimating Concurrent Connections

Requests per second are not sufficient for systems using persistent connections. Chat applications, collaborative editors, multiplayer games, streaming systems, and WebSocket services may maintain millions of concurrent connections even when message throughput is moderate.

Suppose a chat application has:

Daily active users:      50 million
Users online at once:    10%

Concurrent users:
50M × 10%
= 5 million

If each connected user maintains one WebSocket:

≈ 5 million persistent connections

If one connection server safely supports 50,000 concurrent connections:

5,000,000 / 50,000
= 100 servers

That is only the theoretical minimum based on connection count.

Running exactly 100 servers would leave no headroom for failures, deployments, traffic growth, or uneven connection distribution.

If the target is 60% maximum normal utilization:

Usable connections/server:
50,000 × 0.60
= 30,000

Required servers:
5,000,000 / 30,000
≈ 167 servers

This demonstrates an important capacity-planning principle: theoretical maximum capacity is not the same as safe production capacity.

Concurrent connections become a central design constraint in Designing a Chat Application.

Capacity Planning and Headroom

Once workload estimates are available, the next question is how much infrastructure should be provisioned.

A simple application-tier estimate might begin with:

Peak traffic:                30,000 RPS
Safe capacity/server:         1,500 RPS

Minimum servers:
30,000 / 1,500
= 20

Twenty servers provide enough capacity only while every server is healthy and the workload behaves exactly as expected.

Production systems need headroom.

If the target normal utilization is 60%:

Required total capacity:
30,000 / 0.60
= 50,000 RPS

Servers:
50,000 / 1,500
≈ 34 servers

The unused capacity is not necessarily waste. It provides room for:

• traffic spikes;
• instance failures;
• availability-zone failures;
• deployments;
• autoscaling delay;
• temporary dependency slowdown;
• retry amplification.

Plan Capacity After Failures

Suppose 36 application instances are evenly distributed across three availability zones:

Zone A: 12 instances
Zone B: 12 instances
Zone C: 12 instances

If one zone fails:

Remaining instances:
24

Capacity:
24 × 1,500 RPS
= 36,000 RPS

If expected peak traffic is 30,000 RPS, the service still operates after the zone failure:

Failure-state utilization:
30,000 / 36,000
≈ 83%

That is significantly higher than normal utilization but potentially acceptable while autoscaling restores capacity.

This type of calculation is much more useful than simply stating that the application is deployed across three zones.

Account for Autoscaling Delay

Autoscaling should not be treated as instantaneous capacity.

Traffic increases
      |
      v
Metric crosses threshold
      |
      v
Scaling decision
      |
      v
Infrastructure starts
      |
      v
Application initializes
      |
      v
Readiness succeeds
      |
      v
Load balancer registers instance
      |
      v
Usable capacity

If this process takes five minutes, the existing fleet must survive those five minutes.

The relevant question is therefore:

How much load can the current system safely handle until additional capacity becomes usable?

Load-balancing architectures should be sized against failure-state capacity rather than only normal-state capacity. More about this principle can be found in Load Balancing Best Practices for Production Systems.

Production Design Example

Consider a system design interview for a notification platform supporting push, email, and SMS notifications.

Assume:

Daily active users:                 100 million
Notifications/user/day:            10
Peak multiplier:                    4×
Average notification record:       1 KB
Retention:                          30 days
Worker processing capacity:        500 notifications/sec

First calculate daily notification volume:

100M × 10
= 1 billion notifications/day

Average throughput:

1,000,000,000 / 86,400
≈ 11,600 notifications/sec

Peak throughput:

11,600 × 4
≈ 46,400 notifications/sec

At 500 notifications per second per worker:

Theoretical workers:

46,400 / 500
≈ 93 workers

With a target of roughly 60% utilization:

Effective worker capacity:
500 × 0.60
= 300 notifications/sec

Workers:
46,400 / 300
≈ 155 workers

The architecture can use queues to separate notification acceptance from provider delivery:

                       Applications
                            |
                            v
                    Notification API
                            |
                            v
                       Message Queue
                    /        |        \
                   /         |         \
                  v          v          v
             Push Queue   Email Queue   SMS Queue
                 |            |            |
                 v            v            v
              Workers      Workers      Workers
                 |            |            |
                 v            v            v
             Push APIs     Email        SMS
                          Provider     Provider

Storage for 30 days of notification metadata is approximately:

1 billion/day × 1 KB
= 1 TB/day

30 days:
≈ 30 TB raw data

Indexes, replication, database overhead, and backups increase the physical requirement beyond 30 TB.

The queue must also be considered as temporary capacity.

Suppose an external push provider becomes unavailable for 30 minutes while notifications continue arriving at 20,000 push messages per second:

Backlog:

20,000 × 30 × 60
= 36,000,000 notifications

If each queued message occupies approximately 1 KB:

≈ 36 GB of queued payload

More importantly, recovery capacity must exceed incoming traffic or the backlog will never disappear.

If normal incoming traffic is 20,000 notifications per second and workers recover at exactly 20,000 per second:

Incoming:  20,000/sec
Processed: 20,000/sec

Backlog reduction:
0/sec

To clear the backlog, processing throughput must temporarily exceed arrival throughput.

Suppose recovery processing reaches 30,000 per second:

Incoming:           20,000/sec
Processing:         30,000/sec
Backlog reduction:  10,000/sec

36,000,000 / 10,000
= 3,600 seconds
= 60 minutes

A 30-minute provider outage therefore causes another hour of recovery even after the provider becomes healthy.

This is an important capacity-planning lesson: asynchronous systems must be sized not only for normal throughput but also for backlog recovery.

The full architecture and delivery semantics are covered in Designing a Notification System.

Common Mistakes

Interview Checklist

• Start from product assumptions: users, operations per user, payload sizes, retention, and expected concurrency.
• Calculate average RPS: convert daily request volume into requests per second.
• Estimate peak RPS: apply a reasonable and explicit peak multiplier.
• Separate reads and writes: identify which workload dominates the storage layer.
• Estimate storage growth: calculate daily, yearly, and retention-period requirements where relevant.
• Include replication and indexes: distinguish raw data from physical storage consumption.
• Estimate bandwidth: multiply throughput by payload size for data-heavy services.
• Estimate concurrent connections: especially for WebSockets, streaming, chat, and real-time systems.
• Use safe per-instance capacity: avoid designing around theoretical benchmark maximums.
• Maintain headroom: account for spikes, deployments, failures, and workload variation.
• Calculate degraded capacity: verify the system after losing an instance, zone, or other required failure domain.
• Account for autoscaling delay: calculate what the existing fleet must survive before new capacity becomes ready.
• Estimate queue backlogs: model what happens when consumers or external providers become unavailable.
• Plan backlog recovery: ensure processing capacity can exceed incoming traffic after an outage.
• Connect numbers to architecture: every calculation should help justify a design decision or expose a bottleneck.

Conclusion

Scale estimation turns vague system requirements into engineering constraints. Requests per second reveal traffic pressure, storage estimates expose long-term data requirements, bandwidth calculations identify data-delivery bottlenecks, and concurrency estimates reveal the cost of persistent connections.

Capacity planning extends those calculations beyond the theoretical minimum. Production systems need headroom for peaks, failures, deployments, autoscaling delay, and backlog recovery. The most useful capacity number is often not how much traffic the healthy system can process, but how much it can process after something fails.

Key Takeaway

Estimate only the numbers that influence the architecture, but use those numbers consistently. Calculate orders of magnitude for traffic, storage, bandwidth, and concurrency; size infrastructure using safe rather than theoretical capacity; then verify the design under peak load, failure conditions, and recovery. In system design interviews, the value of estimation is not arithmetic precision—it is showing why the architecture needs to look the way it does.

More Articles to Read

• System Design Interviews Explained: What Companies Actually Expect
• Designing a URL Shortener
• Designing a Notification System
• Designing a Chat Application
• Designing a File Storage Service
• Common System Design Interview Mistakes