System Estimation Fundamentals

Why Bother with "Rough" Math?

In a system design interview, you are not expected to be a human calculator. The goal of back-of-the-envelope math is not perfect precision. Instead, it serves three key purposes:

1. Sanity Checking: It helps you quickly determine the order of magnitude of the problem. Will your system need 10 servers or 10,000? Will it store terabytes or petabytes of data? This prevents you from designing a system that is wildly over or under-provisioned.
2. Guiding Design Decisions: The numbers you calculate will directly influence your choice of technologies and architecture. A high read QPS might suggest an aggressive caching strategy. Massive storage needs might point towards a distributed object store like Amazon S3.
3. Meeting Interviewer Expectations: This is a standard part of the system design interview script. Executing it well shows you have a structured, comprehensive approach and can connect business requirements to technical reality.

Let's begin with a short video that explains the purpose and importance of these estimations in the context of a system design interview.

The Art of Approximation: Key Numbers and Techniques

To perform these calculations quickly, you need to simplify. This means rounding numbers aggressively and having a few key figures memorized.

Essential Approximations:

• 1 day ≈ 86,400 seconds. For quick math, round this to 100,000 seconds ($10^5$).
• 1 month ≈ 2.6 million seconds. Round to 2.5 million seconds ($2.5\times 10^6$).
• 1 year ≈ 365 days. Round to 400 for easier multiplication.

Common Data Sizes to Remember:

It's helpful to have a general idea of the size of common data types. You can always state your assumption in an interview, but starting from a reasonable baseline is best.

Here's a handy visual cheat-sheet that summarizes some of these quick calculations.

A Step-by-Step Guide to Estimation

Let's follow a structured approach: first, we'll estimate traffic, then storage, and finally bandwidth.

Step 1: Estimate Traffic (QPS)

Your first goal is to figure out the load on the system in terms of Queries Per Second (QPS). We almost always design for the peak load, not the average.

The Formulas:

1. Average QPS = (Total Daily Requests) / 86,400 seconds
   • Total Daily Requests = Daily Active Users (DAU) * Average Requests per User
2. Peak QPS = Average QPS * Peak Multiplier
   • Traffic is rarely uniform. A 2x to 5x multiplier is a common assumption to account for peak hours.
3. Read vs. Write QPS:
   • Peak Read QPS = Peak QPS * (% Reads)
   • Peak Write QPS = Peak QPS * (% Writes)

Let's watch a clear, worked example of these calculations.

Pro Tip: Use Scientific Notation

Dealing with millions of users and thousands of seconds can lead to unwieldy numbers. Converting to scientific notation (powers of 10) makes multiplication and division much simpler.

• 1 million = $10^6$
• 100,000 seconds = $10^5$ seconds

Dividing $10^6$ by $10^5$ is simply $10^{6-5}=10^1$. This is much easier than doing 1,000,000 / 100,000.

Step 2: Estimate Storage Requirements

Once you know your write traffic, you can estimate storage.

The Formulas:

1. Data Added Per Day = (Total Daily Writes) * (Average Size of an Object)
2. Total Storage = (Data Added Per Day) * 365 * (Number of Years for Retention)
3. Total Storage with Replication = Total Storage * Replication Factor
   • Crucial: Never forget replication! Data is almost always replicated for durability and availability. A replication factor of 3x is a standard assumption.

Let's see an example that involves different types of media, which is a common scenario.

Step 3: Estimate Bandwidth

Bandwidth refers to the data transfer rate your network needs to support. It's derived directly from your QPS and object size estimates.

• Ingress (Incoming Bandwidth): This is the data coming into your system, primarily from writes.
  • Formula: Write QPS * Average Request Size
• Egress (Outgoing Bandwidth): This is the data leaving your system, primarily from reads.
  • Formula: Read QPS * Average Response Size

For example, if your peak write QPS is 500 writes/sec and the average upload size is 100 KB, your ingress requirement is 500 * 100 KB = 50 MB/s.

The Final, Crucial Step: The Sanity Check

After you've run the numbers, take a moment to step back and ask: "Does this make sense?" This is a key differentiator for senior candidates. It shows you're not just mechanically following a formula.

If you calculate that a simple photo-sharing app needs exabytes of storage, you've likely mixed up your units (e.g., KB vs. MB). Catching this yourself is far better than having the interviewer point it out.

Conclusion

In this lesson, you've learned the systematic process for performing back-of-the-envelope calculations. This isn't just about math; it's about building a quantitative foundation for your system design. The estimates you generate will justify your architectural choices in the next stages of the interview.

Key Takeaways:

• State Assumptions Clearly: Always start by stating your assumptions for DAU, usage patterns, and data sizes.
• Approximate Aggressively: Round numbers like seconds in a day ($10^5$) to simplify your calculations.
• Follow the Structure: Calculate QPS (peak, read/write split), then Storage (with retention and replication), and finally Bandwidth (ingress/egress).
• Design for the Peak: Your system must handle the busiest moments, so always apply a peak multiplier to your average traffic.
• Sanity-Check Everything: Step back and evaluate if your numbers are reasonable for the scale of the system you're designing.

In our next lesson, "Create a high-level design diagram including major components and APIs," we will take these estimates and begin to sketch our architecture. Your QPS numbers will tell you that you need a load balancer, and your storage estimates will inform your choice of database and storage systems. This is where the design starts to take shape.