---

Introduction

One of the biggest mistakes engineers make during System Design is jumping directly into architecture without answering a simple question:

How much traffic will the system handle?

Before designing databases, APIs, caches, or microservices, architects estimate:

• Number of users
• Daily Active Users (DAU)
• Requests Per Second (RPS)
• Storage requirements
• Network bandwidth
• Database size
• Cache size
• Number of servers

This process is called Capacity Planning.

Capacity planning helps architects answer questions such as:

• How many servers are required?
• Can one database handle the load?
• Should Redis be introduced?
• Is Kafka required?
• When should we scale horizontally?

Without proper estimation, systems become either over-engineered (expensive) or under-powered (slow and unstable).

---

Learning Objectives

After completing this article, you will understand:

• What is Capacity Planning?
• Why Capacity Planning Matters
• Capacity Planning Workflow
• User Traffic Estimation
• Requests Per Second (RPS)
• Peak Traffic Estimation
• Storage Estimation
• Database Capacity
• Cache Capacity
• Server Capacity
• Network Bandwidth
• Real-World Examples

---

What is Capacity Planning?

Capacity Planning is the process of estimating the infrastructure required to support current and future workloads.

A good estimate considers:

• Users
• Requests
• Data
• Growth
• Performance
• Availability
• Cost

---

Capacity Planning Workflow

flowchart LR
    A[Business Requirements]
    B[Estimate Users]
    C[Estimate Traffic]
    D[Estimate Storage]
    E[Estimate Servers]
    F[Design Architecture]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

---

Step 1 – Estimate Users

Every design starts with users.

Example:

Metric	Value
Registered Users	20 Million
Daily Active Users	5 Million
Peak Concurrent Users	300,000

Never design only for today's traffic.

Always estimate future growth.

---

Step 2 – Estimate Requests

Suppose:

• Daily Active Users = 5 Million
• Average Requests/User = 40

Daily Requests

5,000,000 × 40

=

200,000,000 Requests/Day

---

Step 3 – Calculate Requests Per Second (RPS)

Formula

Requests Per Second

=

Daily Requests

÷

86,400 Seconds

Example

200,000,000

÷

86,400

=

2,315 RPS

Average RPS = 2,315

---

Peak RPS

Traffic is not evenly distributed.

Peak traffic is often 3–10× higher than average.

Example

Average RPS

2,300

↓

Peak Factor

5×

↓

Peak RPS

11,500

Architects always design for peak traffic, not average traffic.

---

User Traffic Growth

flowchart LR
    A[10K Users]
    B[100K Users]
    C[1 Million Users]
    D[10 Million Users]

    A --> B
    B --> C
    C --> D

---

Real-Time Banking Example

Suppose a banking application has:

• 12 Million customers
• 2 Million daily active users
• 30 API calls/customer/day

Daily Requests

2,000,000

×

30

=

60 Million Requests

Average RPS

60,000,000

÷

86,400

≈

694 RPS

Peak

694 × 8

≈

5,500 RPS

Your architecture must comfortably support 5,500+ RPS.

---

Storage Estimation

Suppose each transaction stores:

• Customer ID
• Amount
• Timestamp
• Status
• Metadata

Average Record Size

2 KB

Transactions

20 Million/Day

Daily Storage

20M × 2KB

≈

40 GB/Day

Yearly Storage

40 GB × 365

≈

14.6 TB

Storage planning directly affects database design.

---

Storage Growth

flowchart TD
    A[40 GB / Day]
    B[1.2 TB / Month]
    C[14.6 TB / Year]

    A --> B
    B --> C

---

Database Capacity Planning

Example

flowchart LR
    A[Application]

    B[(Primary Database)]

    C[(Read Replica)]

    A --> B
    A --> C

Questions

• How many writes/sec?
• How many reads/sec?
• How large is each row?
• Index size?
• Backup size?

---

Read vs Write Ratio

Most systems perform more reads than writes.

Example

Operation	Percentage
Reads	90%
Writes	10%

If reads dominate:

Use:

• Read Replicas
• Redis
• CDN

---

Cache Capacity Planning

Frequently accessed data should be cached.

flowchart LR
    A[Application]

    B[Redis Cache]

    C[(Database)]

    A --> B
    B --> C

Example

Frequently accessed:

• User Profile
• Product Details
• Exchange Rates
• Branch Details

Estimate

500,000 Cached Objects

×

5 KB

=

2.5 GB Redis

---

Server Capacity Planning

Suppose

One Spring Boot server handles:

1,200 Requests/sec

Peak Traffic

12,000 RPS

Servers Required

12,000

÷

1,200

=

10 Servers

Always add spare capacity.

Recommended

10 Servers

↓

+30%

↓

13 Servers

---

Load Balancer Architecture

flowchart TD
    A[Users]

    B[Load Balancer]

    C[App 1]

    D[App 2]

    E[App 3]

    F[App 4]

    A --> B

    B --> C
    B --> D
    B --> E
    B --> F

---

Network Bandwidth Planning

Suppose

Average Response Size

100 KB

Peak Requests

12,000 RPS

Bandwidth

100 KB

×

12,000

=

1.2 GB/sec

Architects estimate network traffic before deployment.

---

Queue Capacity

For asynchronous systems:

flowchart LR
    A[Orders]

    B[Kafka]

    C[Consumers]

    A --> B
    B --> C

Questions

• Queue size?
• Message size?
• Consumer speed?
• Peak backlog?

---

Capacity Planning for Microservices

flowchart TD
    A[API Gateway]

    B[User Service]

    C[Order Service]

    D[Payment Service]

    E[Notification Service]

    A --> B
    A --> C
    A --> D
    A --> E

Estimate capacity independently for each service because traffic patterns differ.

---

Real-World Example — Amazon

Amazon estimates:

• Peak shopping traffic
• Black Friday load
• Checkout requests
• Payment volume
• Inventory updates
• Search requests

Infrastructure automatically scales during major sales events.

---

Real-World Example — Netflix

Netflix estimates:

• Concurrent viewers
• Video bitrate
• CDN bandwidth
• Streaming sessions
• Regional traffic

Capacity planning ensures smooth streaming even during global premieres.

---

Real-World Example — WhatsApp

WhatsApp estimates:

• Messages/sec
• Image uploads
• Voice calls
• Online users
• Push notifications

Message queues and distributed servers handle billions of daily messages.

---

Real-World Example — Uber

Uber estimates:

• Ride requests/sec
• Driver location updates
• GPS events
• Payment transactions

Peak demand occurs during holidays, concerts, and sporting events.

---

Capacity Planning Checklist

Before designing any system, estimate:

✅ Registered Users

✅ Daily Active Users

✅ Peak Concurrent Users

✅ Requests Per Second

✅ Storage Growth

✅ Database Size

✅ Cache Size

✅ Server Count

✅ Network Bandwidth

✅ Future Growth (2–5 years)

---

Common Mistakes

❌ Designing without traffic estimates

❌ Ignoring peak load

❌ No storage forecasting

❌ No cache sizing

❌ Underestimating growth

❌ Forgetting backup storage

❌ Assuming average traffic is enough

---

Best Practices

• Estimate before designing.
• Design for peak traffic, not average traffic.
• Plan for at least 2–5 years of growth.
• Keep 20–30% spare infrastructure capacity.
• Cache frequently accessed data.
• Scale horizontally whenever possible.
• Continuously monitor actual traffic and adjust capacity.
• Perform load and stress testing before production.
• Review estimates regularly as the business grows.

---

Common Interview Questions

What is Capacity Planning?

Capacity Planning is the process of estimating the infrastructure, storage, network, and computing resources required to support current and future workloads.

---

Why do architects estimate Peak RPS instead of Average RPS?

Traffic is uneven throughout the day. Systems must remain stable during peak demand, not just average usage.

---

How do you calculate Requests Per Second (RPS)?

RPS = Daily Requests ÷ 86,400

where 86,400 is the number of seconds in a day.

---

Why is storage estimation important?

Storage estimates influence database selection, partitioning, backup strategy, disaster recovery planning, and infrastructure costs.

---

Why should capacity planning include future growth?

Applications typically grow over time. Designing only for current traffic can lead to costly redesigns and production outages.

---

Summary

Capacity Planning is one of the first responsibilities of a System Architect. Before choosing technologies or drawing architecture diagrams, architects estimate how much traffic, data, and infrastructure the system must support.

In this article, we covered:

• Capacity Planning fundamentals
• User estimation
• Traffic estimation
• Requests Per Second (RPS)
• Peak load calculations
• Storage estimation
• Database capacity
• Cache sizing
• Server sizing
• Network bandwidth
• Queue capacity
• Real-world examples
• Best practices

Accurate capacity planning helps build systems that are scalable, cost-effective, and prepared for future growth, avoiding both over-engineering and unexpected production failures.

---