System Design Capacity Estimation

Capacity estimation predicts how much traffic, storage, and bandwidth a system needs. Designers run quick calculations before they choose servers or databases. Rough numbers are enough. The goal is to learn whether the system needs one server or one thousand.

Why Estimation Matters

A wrong guess wastes money or crashes the app. Too few servers make the site slow during a sale. Too many servers burn budget with no benefit. A simple estimate gives the team a safe starting point.

Layman example

A wedding planner counts guests before ordering food. The planner does not need an exact headcount. A close number prevents hunger and waste.

Handy Numbers to Remember

• One day holds 86,400 seconds. Round it to 100,000 for fast math.
• One million requests per day equals about 12 requests per second.
• 1 KB is 1,000 bytes. 1 MB is 1,000 KB. 1 GB is 1,000 MB. 1 TB is 1,000 GB.
• Peak traffic often reaches 2 to 3 times the daily average.

The Estimation Pipeline

Every estimate follows the same path. Start with users and end with servers.

Daily Users
    |
    v
Requests per Day  -->  Requests per Second (average and peak)
    |
    v
Data per Request  -->  Storage per Day  -->  Storage per Year
    |
    v
Bandwidth (data moved each second)
    |
    v
Number of Servers

Worked Example: A Photo Sharing App

Assume the app has 1 million daily active users. Each user opens the app and makes 10 requests per day. One user in ten uploads two photos, and each photo weighs 2 MB.

Step 1: Requests per Second

Total requests per day = 1,000,000 x 10 = 10,000,000. Divide by 86,400 seconds and the result is about 115 requests per second. Peak traffic reaches roughly 3 times that value, which equals about 350 requests per second.

Step 2: Storage per Day

Uploading users = 100,000. Photos per day = 100,000 x 2 = 200,000. Storage per day = 200,000 x 2 MB = 400,000 MB, which equals 400 GB.

Step 3: Storage per Year

400 GB x 365 days = 146,000 GB, or about 146 TB. Teams usually add a safety margin of 20 to 30 percent and plan copies of every file. Three copies raise the need to about 440 TB.

Step 4: Bandwidth

Incoming data per day = 400 GB. Divide by 86,400 seconds and the result is about 4.6 MB per second. Viewers download photos far more often than users upload them. Assume a read-to-write ratio of 20 to 1. Outgoing bandwidth reaches roughly 92 MB per second.

Step 5: Servers

One server handles about 100 to 500 simple requests per second. A peak of 350 requests per second fits on a few servers. Teams run at least two or three servers for safety.

Read-Heavy vs Write-Heavy Systems

The ratio between reads and writes shapes the design. A news site is read-heavy, so caching and replicas bring big gains. A messaging app writes constantly, so fast write storage matters more. Estimating this ratio early points the design in the right direction.

Tips for Better Estimates

• State every assumption out loud or in writing.
• Round numbers to keep math simple.
• Estimate peak load, not only the average.
• Add growth for the coming one to three years.
• Recheck numbers after launch with real traffic data.

Common Mistakes

Beginners often forget copies of data. Others ignore peak hours or skip the read-to-write ratio. A small error in an early assumption grows large at scale, so clear notes help the team fix mistakes quickly.