Estimating Capacity: Back-of-the-Envelope Calculations

Hello! Welcome back to your system design course.

In our last lesson, we established a framework for tackling system design problems, focusing on the crucial first step: gathering requirements. We took a vague prompt like "Design a photo-sharing service" and defined its functional scope (e.g., uploads, feeds) and non-functional constraints (e.g., 10 million users, fast feed loads).

Today's Goal

Today, we'll build directly on that foundation. We will learn how to estimate capacity requirements using back-of-the-envelope calculations for user traffic, storage, and bandwidth.

This step translates the abstract requirements we gathered into concrete numbers. It's the bridge between understanding what to build and figuring out how much we need to build it. Just as a product designer might estimate material quantities and costs based on production volume, a system designer estimates server, storage, and network needs based on user load. This skill is essential for making informed architectural decisions and demonstrating a practical, engineering mindset.

Let's get started.

---

1. What are Back-of-the-Envelope Calculations?

"Back-of-the-envelope calculation" (BOTEC) is a term for a quick, simplified, and approximate calculation. The goal isn't mathematical perfection but to get an "order of magnitude" estimate. Are we dealing with 10 requests per second or 10,000? Do we need a few gigabytes of storage or many petabytes? The answers to these questions fundamentally shape the design.

To get a feel for what this means in practice, let's start with a short video from ByteByteGo.

As the video explains, these estimates help us make initial, high-level decisions. For example:

• If we calculate that we need to handle 10 queries per second, a single database server is likely sufficient for now.
• If we calculate 1 million requests per second, we know immediately that we'll need a large fleet of servers and a load balancer.

In an interview, performing these calculations shows that you can think quantitatively about a system's scale and make data-informed trade-offs.

---

2. The Core Skill: Simplifying Large Numbers

The key to performing these calculations quickly and confidently is to simplify the math. You are not expected to multiply large, precise numbers in your head. The universal approach is to round numbers and use powers of 10.

Key Principles:

• Approximate Aggressively: Round numbers to make them easy to work with.
  • Seconds in a day: 24 × 60 × 60 = 86,400 ≈ 100,000 (or 10⁵)
  • Days in a year: 365 ≈ 400
• Know Your Powers of 10: Memorizing these prefixes is non-negotiable.

Prefix	Value	Power of 10
Kilo (K)	Thousand	103
Mega (M)	Million	106
Giga (G)	Billion	109
Tera (T)	Trillion	1012
Peta (P)	Quadrillion	1015

The following video provides an excellent, clear walkthrough of how to use these powers of 10 in calculations.

By converting numbers like "150 million" to 1.5 × 10⁸ and "100 kilobytes" to 10⁵ bytes, complex multiplication and division become simple addition and subtraction of exponents.

---

3. The Three Pillars of Estimation

We will focus on three main types of estimates: traffic, storage, and bandwidth.

A. Traffic Estimation (Requests Per Second)

This is usually the first and most important estimate. It tells us how much work our system has to do every second.

The Formula:
Traffic (Requests Per Second, or QPS/RPS) = (Number of Users × Actions per User) / Time Period in Seconds

The Process:

1. Start with the number of Daily Active Users (DAU).
2. Estimate the number of write actions (e.g., posting a photo, sending a message). Often, only a fraction of users create content.
3. Estimate the read-to-write ratio. Systems are usually "read-heavy" (e.g., you view more tweets than you write) or "write-heavy" (e.g., a logging service).
4. Calculate the total number of read and write requests per day.
5. Divide by the number of seconds in a day (~100,000) to get the average QPS.
6. Consider peak traffic. Usage isn't uniform; you might multiply the average by a factor (e.g., 2x to 5x) to estimate the peak load your system must handle.

This video provides a great walkthrough of this process.

B. Storage Estimation

This tells us how much disk space we'll need.

The Process:

1. Start with the number of new items created per day (from your write traffic estimate).
2. Estimate the average size of each item (e.g., text ≈ 1 KB, photo ≈ 2 MB, 1 min video ≈ 50 MB).
3. Calculate the new data added per day.
4. Multiply by the data retention period (e.g., store photos for 10 years).
5. Multiply by the replication factor (data is usually copied for reliability; a factor of 3 is a standard assumption).

Let's watch a walkthrough of this calculation.

C. Bandwidth Estimation

This tells us how much data our network needs to handle per second. It's derived directly from our traffic and storage estimates.

• Ingress (Incoming Bandwidth): Write QPS × Size of each write.
• Egress (Outgoing Bandwidth): Read QPS × Size of each read.

This final clip explains it concisely.

---

4. Let's Practice: The Photo-Sharing App

Let's apply these steps to the photo-sharing app from our last lesson.

Recall our assumptions:

• Daily Active Users (DAU): 1 million (10⁶)

Your turn! Before looking at my calculations below, take 5-10 minutes and try to estimate the traffic (read/write QPS), total storage, and bandwidth.

State your own assumptions for:

• Percentage of users who upload a photo daily.
• Average number of photos uploaded per uploader.
• Read-to-write ratio.
• Average photo size.
• Data retention period.
• Replication factor.

Click here to see my step-by-step calculation.

My Assumptions:

• Writes: 10% of DAU upload 2 photos per day.
• Reads: The system is read-heavy with a 100:1 read-to-write ratio.
• Data Size: Average photo size is 2 MB.
• Retention & Replication: Data is kept forever (let's plan for 10 years) and replicated 3 times.

---

1. Traffic Estimation

• Write Requests per day:
  1M DAU × 10% uploaders × 2 photos/uploader = 200,000 writes/day.
• Write QPS (Average):
  200,000 writes / 100,000 seconds/day = 2 writes/sec.
• Read Requests per day:
  200,000 writes/day × 100 (read/write ratio) = 20,000,000 reads/day.
• Read QPS (Average):
  20M reads / 100k seconds/day = 200 reads/sec.

Result: We need to handle ~2 writes and ~200 reads per second on average.

---

2. Storage Estimation

• New data per day:
  200,000 new photos/day × 2 MB/photo = 400,000 MB/day = 400 GB/day.
• Total data in 10 years:
  400 GB/day × 365 days/year × 10 years ≈ 400 GB/day × 400 days/year × 10 years = 1,600,000 GB = 1.6 PB (Petabytes).
• Total data with replication:
  1.6 PB × 3 replicas = 4.8 PB.

Result: We need to plan for nearly 5 petabytes of storage over 10 years.

---

3. Bandwidth Estimation

• Ingress (Uploads):
  2 writes/sec × 2 MB/photo = 4 MB/s.
• Egress (Downloads/Feed Views):
  200 reads/sec × 2 MB/photo = 400 MB/s.

Result: The system needs to support 4 MB/s of incoming traffic and a much larger 400 MB/s of outgoing traffic.

---

Conclusion

Great work today! This was a dense, numbers-focused lesson, but mastering this skill is what separates a high-level idea from a plausible system design.

Key Takeaways:

• Purpose over Precision: Back-of-the-envelope calculations are for understanding scale and making informed architectural choices, not for exact resource provisioning.
• State Your Assumptions: Always clearly state the assumptions you're making (DAU, read/write ratio, data sizes, etc.).
• Simplify the Math: Round aggressively and use powers of 10. The goal is speed and clarity, not precision.
• Follow the Flow: The estimations are linked. Traffic estimates feed into storage and bandwidth calculations. Start with users, calculate traffic (QPS), then use that to find storage and network needs.

Preview of the Next Lesson:
Now that we have a quantitative feel for our system's scale (e.g., 200 reads/sec, ~5 PB of storage), we can start designing the high-level architecture. In the next lesson, we will analyze trade-offs between monolithic, microservices, and serverless architectures. Our capacity estimates will be a key factor in deciding which of these patterns is the best fit for our photo-sharing service.