Durgesh Tiwari
Author
Before designing the architecture of a software system, you need to understand how large the system will be. This process is called System Design estimation.
Estimation helps engineers make realistic assumptions about the expected number of users, traffic, storage, and infrastructure required to support an application. These estimates guide architecture decisions and help determine whether a simple design is enough or a distributed system is needed.
The goal isn't to calculate exact numbers. Instead, you make reasonable estimates that are accurate enough to design a scalable and cost-effective system.
For this reason, estimation is one of the first steps in almost every System Design interview.
Estimation is the process of calculating the approximate resources a system needs to handle its expected workload.
Engineers typically estimate:
Number of users
Requests per second (RPS/QPS)
Storage requirements
Network bandwidth
Number of servers
These estimates provide a clear understanding of the system's scale and form the foundation for architecture decisions.
For example, they help determine whether the application needs caching, load balancing, database sharding, or multiple application servers.
Every architecture decision depends on the expected scale of the application.
For example, a system serving 500 users requires a very different architecture from one serving 50 million users. As traffic and data grow, the infrastructure must also scale to maintain performance and reliability.
Estimation helps engineers:
Design scalable systems
Choose the right infrastructure
Estimate storage and bandwidth requirements
Avoid unnecessary costs
Identify potential bottlenecks early
Explain design decisions during System Design interviews
In interviews, the reasoning behind your estimates is usually more important than arriving at the exact numbers.
Before designing the architecture of any software system, you need to estimate its expected workload and resource requirements. These estimates help you understand the scale of the application and make better architecture decisions.
In most System Design interviews, engineers estimate the following:
Number of users
Requests per second (RPS)
Peak traffic
Read and write ratio
Storage requirements
Data growth
Bandwidth requirements
Memory requirements
Let's understand each of them.
The first step is estimating how many people will use the application because it directly affects traffic, storage, and infrastructure planning.
Common user metrics include:
Registered Users – Total users who have signed up.
Daily Active Users (DAU) – Users who use the application every day.
Monthly Active Users (MAU) – Users who use the application at least once a month.
Concurrent Users – Users who are active at the same time.
Example
Suppose a food delivery application has:
5 million registered users
1 million daily active users
100,000 concurrent users during peak hours
These numbers help estimate the expected system traffic.
Requests Per Second (RPS) measures how many requests the system receives every second. It is one of the most important estimations in System Design because it helps determine the expected load on servers, APIs, databases, and caches.
Simple Formula
RPS = Total Requests Per Day ÷ 86,400Example
If users generate 86.4 million requests per day:
86,400,000 ÷ 86,400 = 1,000 RPSThe application receives approximately 1,000 requests every second.
User traffic is rarely the same throughout the day. Most applications experience peak hours when the number of requests increases significantly.
For example:
Food delivery apps receive more orders during lunch and dinner.
Video streaming platforms become busier in the evening.
E-commerce websites experience traffic spikes during sales and festivals.
Depending on the application, peak traffic is often estimated as 2× to 5× the average traffic. Designing for peak traffic helps prevent slowdowns and outages during busy periods.
Most applications receive more read requests than write requests. Estimating this ratio helps engineers choose the right database architecture, caching strategy, and replication model.
Examples
Application | Typical Read : Write Ratio |
|---|---|
Social Media | 100 : 1 |
News Website | 500 : 1 |
E-commerce | 20 : 1 |
Banking | 1 : 1 to 5 : 1 |
Applications with a high read ratio usually benefit from caching and read replicas.
Every application stores data, so estimating storage requirements is essential for capacity planning.
Common storage estimates include:
Number of records
Average record size
Daily storage growth
Yearly storage growth
Suppose:
One image = 2 MB
Users upload 500,000 images per day
Daily Storage Requirement
500,000 × 2 MB = 1 TBYearly Storage Requirement
1 TB × 365 ≈ 365 TBThese estimates help engineers choose the right storage architecture and backup strategy.
Storage requirements continue to increase as users create more data over time. Estimating future data growth helps prevent storage shortages and supports long-term capacity planning.
Example
If an application stores 1 TB of new data every day, it will require approximately:
30 TB per month
365 TB per year
This estimation helps plan future storage expansion.
Bandwidth is the amount of data transferred between users and the application every second.
It is especially important for:
Video streaming platforms
File upload systems
Image sharing applications
Live streaming services
Example
Suppose:
Average response size = 200 KB
Requests per second = 1,000
1,000 × 200 KB = 200 MB/secondThis estimate helps determine the required network capacity.
Frequently accessed data is often stored in memory instead of being fetched from the database every time. Estimating memory requirements helps determine the size of caching systems.
Memory estimation is commonly used for:
Redis cache
Session storage
Frequently accessed data
In-memory databases
Example
Suppose:
One cached object = 5 KB
Cached objects = 2 million
2,000,000 × 5 KB ≈ 10 GBThis helps estimate the required cache memory.
In System Design interviews, interviewers expect quick approximations rather than perfectly accurate calculations. These rough calculations are called Back-of-the-Envelope Estimations.
The goal is to make reasonable assumptions that help design a scalable architecture.
Example
Instead of calculating the exact storage required for a social media platform, you can estimate:
Number of users
Posts created per day
Average post size
Daily and yearly data growth
These estimates are usually sufficient to make informed architecture decisions during interviews.
Many beginners make similar mistakes during System Design estimation. Avoid these common errors:
Skipping estimation and jumping straight to architecture.
Using unrealistic numbers without explaining assumptions.
Ignoring peak traffic and future growth.
Estimating only storage while overlooking bandwidth and memory.
Focusing on exact calculations instead of reasonable approximations.
Keep these best practices in mind:
Start with simple and realistic assumptions.
Explain how you arrived at each estimate.
Estimate users and traffic before infrastructure.
Plan for peak traffic and future growth.
Keep calculations simple, logical, and easy to explain.