Capacity Estimation: System Design
Last Post : https://medium.com/@adarshmelath1305/scalability-system-design-1fd373f5a550 ( Scalability in System Design )
Before cooking for a family gathering, my mother always asks one simple question:
“How many people are eating today?”
Once she has an approximate number, she quickly estimates how much rice, vegetables, and spices will be needed. It’s not an exact calculation. Instead, it’s a rough estimation to make sure there is enough food for everyone while also avoiding unnecessary waste.
If she cooks too little, some people might not get enough food.
If she cooks too much, a lot of food may go to waste.
So she finds a balanced approximation.
Interestingly, software engineers follow a very similar approach when designing large-scale systems.
Before building a system, engineers try to estimate things like:
- How many users will use the product?
- How many requests will the system receive per second?
- How much data will be generated and stored every day?
- How much bandwidth and infrastructure will be required?
These estimations help engineers understand the expected scale of the system before they start building it.
This process is called capacity estimation, and it is one of the most important steps in system design.
What is Capacity Estimation?
Capacity estimation is the process of predicting how many resources a system will need to handle users and data smoothly.
In simple terms, it helps engineers answer questions like:
- How much storage is needed?
How much space is required to store all the data (images, videos, posts, etc.). - How many requests per second (RPS)?
How many actions users perform every second (opening an app, sending a message, refreshing a page). - Read vs Write ratio
How often data is read (viewing a post) compared to how often it is written (creating a post or uploading a photo). - Network bandwidth
How much data needs to travel through the internet between users and servers. - Memory usage
How much temporary fast storage (RAM) the system needs to process requests quickly. - Number of machines (servers)
How many computers are required to run the system and handle all the users.
Why need to estimate the capacity ?
Capacity estimation is calculated to ensure a system has enough resources (servers, storage, bandwidth) to handle users without crashing. It also helps avoid wasting money on unnecessary infrastructure. In simple terms, it helps engineers design systems that can run efficiently at scale.
How to Estimate ?
In system design, we usually don’t have exact data about the number of users, traffic, or data size. Because of this, engineers start with reasonable assumptions before doing any calculations.
In real system design interviews, interviewers expect candidates to clearly state their assumptions first. This shows that you understand how to approach large-scale systems logically.
For example, we might assume:
- Total users: 10 million
- Daily active users: 1 million
- Requests per user per day: 20
- Average request size: 2 KB
- Read vs Write ratio: 80:20
These assumptions help us estimate the scale of the system and perform further calculations.
What need to Estimate ?
Step 1: Estimate System Traffic
After defining assumptions, the next step is to estimate how much traffic the system will receive.
Traffic estimation helps us understand how many requests the system must handle, which directly determines the load on servers, databases, and networks.
The most common metric used here is Requests Per Second (RPS).
For example, if we know how many requests happen in a day, we can convert that number into requests per second to understand the real-time load on the system.
Important Formulas to Remember
1. Total Daily Requests
Total Daily Requests =
Daily Active Users × Requests per User per Day
2. Requests Per Second (RPS)
Requests Per Second =
Total Daily Requests ÷ 86,400
(86,400 = number of seconds in a day)
2. Requests Per Second (RPS)
Requests Per Second =
Total Daily Requests ÷ 86,400
(86,400 = number of seconds in a day)
Example
If:
- Daily active users = 1,000,000
- Requests per user per day = 20
Then:
Total Daily Requests =
1,000,000 × 20 = 20,000,000 requests per day
Requests Per Second =
20,000,000 ÷ 86,400 ≈ 231 RPS
This means the system must be capable of handling around 231 requests every second.
Step 2: Estimate Storage Requirements
After estimating traffic, the next step is to calculate how much data the system will store over time.
This helps engineers decide how much database storage is needed and how the system should scale as data grows.
Things We Need to Estimate
- Size of one record — How much storage one piece of data takes (for example, one post, message, or record).
- Data generated per day — Total data created by users in one day.
- Data generated per year — Total data the system stores over a year.
Important Formulas to Remember
1. Daily Storage
Daily Storage =
Number of Records per Day × Size of One Record
2. Yearly Storage
Yearly Storage =
Daily Storage × 365
Example
Assume:
- Size of one record = 1 KB
- Records created per day = 1,000,000
Then:
Daily Storage =
1,000,000 × 1 KB = 1 GB per day
Yearly Storage =
1 GB × 365 = ≈ 365 GB per year
Replication Factor (Important for Reliability)
In real systems, data is usually stored on multiple servers to prevent data loss if one server fails. This is called replication.
For example:
If the replication factor = 3
Total Storage Needed =
365 GB × 3 = ≈ 1.1 TB
This ensures the system remains reliable and fault-tolerant.
Step 3: Estimate Network Bandwidth
After estimating storage and traffic, the next step is to estimate how much data will travel through the network. This is called bandwidth estimation.
Bandwidth estimation helps engineers understand how much data is transferred between users and servers every second, which is important for choosing the right network capacity.
Important Formula to Remember
Bandwidth = Request Size × Requests Per Second (RPS)
Example
Assume:
- Average request size = 2 KB
- Requests per second = 200
Then:
Bandwidth =
2 KB × 200 = 400 KB per second
This means the system must be able to handle 400 KB of data transfer every second.
Step 4: Estimate Memory / Cache Requirements
In large systems, some data is accessed very frequently. If every request goes directly to the database, it can slow down the system and increase database load.
To solve this problem, systems use caching.
A cache is a fast memory (RAM) that stores frequently used data so the system can return results much faster without always querying the database.
When is Caching Needed?
Caching is useful when:
- Some data is requested very frequently
- We want to reduce the number of database queries
- We want to improve response time
Cache Size Estimation
A common assumption in system design is that about 20% of the data is accessed 80% of the time (known as the 80–20 rule).
Get Adarsh Melath’s stories in your inbox
Join Medium for free to get updates from this writer.
So we often cache the top 20% of frequently accessed data.
Example
Assume:
- Total stored data = 100 GB
- Frequently accessed (hot) data = 20%
Cache size needed =
20% × 100 GB = 20 GB
This means we may need around 20 GB of cache memory to store frequently accessed data.
Step 5: Estimate Number of Servers
determine how many servers are needed to handle the system load.
Each server can handle only a limited number of requests per second. By comparing the system’s total traffic with the capacity of one server, we can estimate the number of machines required.
Important Formula
Number of Servers = Total Requests per Second ÷ Requests handled by one server
Example
Assume:
- System traffic = 5000 requests per second
- One server can handle = 1000 requests per second
Then:
Servers required =
5000 ÷ 1000 = 5 servers
Why Do We Add a Buffer?
In real systems, traffic is not always constant. Sometimes there are traffic spikes (sudden increase in users), such as during sales, events, or viral content.
To handle these situations safely, engineers usually add a buffer of extra servers.
Example:
Required servers = 5
With buffer = 7–8 servers
This ensures the system remains stable even during sudden traffic increases.
Step 6: Understand the Read vs Write Ratio
In most systems, reads (fetching data) happen much more often than writes (creating or updating data).
Example:
- Reads: 90% (users viewing posts, messages, timelines)
- Writes: 10% (users creating posts, sending messages)
This ratio is important because it affects how we design the system.
How It Affects System Design
1. Database Choice
If a system has many reads, we may use databases optimized for fast read operations.
2. Caching Strategy
When reads are very high, frequently accessed data can be stored in cache to reduce database load.
3. Replication
We can create multiple read replicas of the database so that read requests are distributed across several servers.
Real-World Example: Capacity Estimation for a URL Shortener
To understand capacity estimation better, let’s apply the whole process to a simple system like a URL Shortener (similar to Bitly).
Step 1: Assumptions
First, we define some reasonable assumptions
- Total users: 10 million
- Daily active users: 1 million
- URLs created per user per day: 2
Step 2: Traffic Estimation
First, we calculate the total number of requests.
Daily Requests
Daily requests =
1M × 2 = 2M requests per day
Requests Per Second (RPS)
RPS =
2,000,000 ÷ 86,400 ≈ 23 requests per second
Step 3: Read vs Write Ratio
In a URL shortener system, users create URLs occasionally but access them very frequently.
Assumption:
- Writes (creating short URLs): 10%
- Reads (redirecting URLs): 90%
From 23 RPS:
- Writes: 10% × 23 ≈ 2 writes/sec
- Reads: 90% × 23 ≈ 21 reads/sec
This shows that the system will mostly handle read traffic, so caching and read replicas can help improve performance.
Step 4: Storage Estimation
Assume:
- One shortened URL record = 500 bytes
Daily Storage
2,000,000 × 500B ≈ 1 GB per day
Yearly Storage
1 GB × 365 ≈ 365 GB per year
If we use replication factor = 3 for reliability:
Total storage ≈ 365 GB × 3 ≈ 1.1 TB
Step 5: Bandwidth Estimation
Assume:
- Average request size = 1 KB
- Requests per second = 23
Bandwidth =
1 KB × 23 ≈ 23 KB per second
This tells us how much network capacity the system needs to handle user requests.
Step 6: Server Estimation
Assume:
- One server can handle 1000 requests per second
System traffic:
23 RPS
Servers required:
23 ÷ 1000 ≈ 1 server
However, we always add extra servers as a buffer to handle sudden traffic spikes and future growth.
So in practice, we might deploy 2–3 servers.
Data Size Conversions (Useful for Capacity Estimation)
When estimating storage and bandwidth, we often convert between different data units.
Basic conversions to remember:
- 1 KB = 1024 Bytes
- 1 MB = 1024 KB
- 1 GB = 1024 MB
- 1 TB = 1024 GB
Quick Reference
- 1KB ≈ 1⁰³ bytes
- 1 MB ≈ 1⁰⁶ bytes (1 million)
- 1 GB ≈1⁰⁹ bytes (1 billion)
- 1 TB ≈ 1⁰¹² bytes( 1 Trillion)
Simple Tip for System Design
In most system design interviews, engineers often use approximate values for quick calculations:
- 1 KB ≈ 1000 Bytes
- 1 MB ≈ 1000 KB
- 1 GB ≈ 1000 MB
This makes calculations much faster during interviews.
Conclusion
Remember: in system design, rough numbers are far better than no numbers.
