In our previous lesson, we established the crucial first step in any system design interview: gathering and clarifying requirements. We learned how to transform a vague prompt into a well-defined set of functional and non-functional goals. Now, we'll take the next logical step by translating those abstract requirements into concrete, quantifiable engineering targets.
This lesson focuses on a skill that interviewers highly value as a signal of seniority: back-of-the-envelope estimation. You'll learn how to quickly estimate the scale, data, and traffic your system needs to handle. This isn't about precise accounting; it's about making reasonable, grounded assumptions that will inform every architectural decision you make, from choosing a rendering strategy to designing a caching layer.
The Why and What of Estimation
Before we dive into calculations, it's important to understand the role of estimation in a system design interview. The goal is not to produce a perfect number but to demonstrate a structured thought process and an intuitive feel for scale. Grounding your design in numbers from the outset prevents you from proposing solutions that are either wildly over-engineered or insufficient for the expected load.
Back of the Envelope Calculation: A Practical Guide
This guide from the System Design Handbook clearly explains why estimation is a key differentiator for senior candidates and what it truly means in an interview context.
Please read the introduction, starting from the beginning of the article. Pay close attention to the distinction between what estimation is (fast, reasonable, directional) and what it is not (mental math tricks, premature optimization).
As the article emphasizes, these calculations set the foundation for your entire design. Let's look at a quick example of how this works in practice.
Back-Of-The-Envelope Estimation / Capacity Planning
This video from ByteByteGo offers a concise summary of the purpose of back-of-the-envelope math.
Watch the initial segment from the introduction. Notice how a simple estimation immediately leads to a concrete architectural decision: the need for multiple servers and a load balancer.
The Building Blocks: Core Units and Latency
To perform these estimations effectively, you need to be fluent in the basic units of scale and have a strong intuition for performance trade-offs.
First, let's review the core units for time, traffic, and data size. Being comfortable with these conversions allows you to move quickly from user numbers to storage needs or request rates without getting bogged down in arithmetic.
Back of the Envelope Calculation: A Practical Guide
This section of the guide provides a handy reference for the common units you'll use.
Review the tables under the heading Core Units You Must Be Fluent With. You don't need to memorize every number, but you should internalize the orders of magnitude (e.g., ~86,400 seconds in a day, a text record is hundreds of bytes, an image is hundreds of kilobytes).
Beyond basic units, a deep understanding of latency is arguably the most critical intuition for a system designer. Knowing the relative cost of a CPU cache hit versus a network round trip is what allows you to identify and solve performance bottlenecks effectively.
System Design Interview Vol. 1 Ch. 2 - Back-of-the-Envelope Estimation | Noah Tigner
This article provides an excellent summary of Jeff Dean's classic "Latency Numbers Every Programmer Should Know," along with an updated version specifically for frontend developers.
Please study the two tables in the section Latency Numbers. The key takeaway isn't the exact nanosecond values, but the relative differences. Notice how quickly network operations dominate local compute. For frontend design, the second table is particularly relevant, as it includes budgets for frame rendering and asset parsing.
A Framework for Estimation
Great estimations aren't improvised; they follow a clear, repeatable process. Adopting a structured approach ensures you don't miss crucial steps and makes your reasoning easy for the interviewer to follow.
Here is a five-step framework that you can apply to any estimation problem:
- Clarify the Goal: State exactly what you are trying to estimate (e.g., "First, I'll estimate the peak write traffic to determine the load on our API servers.").
- State Assumptions: Explicitly list your assumptions about user numbers, behavior, and data sizes. This is a collaborative step; your interviewer may offer adjustments.
- Decompose the Problem: Break the large problem into smaller, manageable parts (e.g., to get storage, first find data per day, then multiply by retention period).
- Estimate Components: Calculate each part using simple, rounded numbers. Use scientific notation to handle large figures easily.
- Sanity Check: Review the final number. Does it feel reasonable? Acknowledge if a number seems too high or low and reconsider your assumptions. This self-correction is a very positive signal.
This systematic approach is detailed in the "Back of the Envelope Calculation" guide. I encourage you to read through it to solidify your understanding of the process.
Putting It into Practice: Traffic, Storage, and Bandwidth
Now, let's apply this framework to the three most common estimations you'll need to make: traffic, storage, and bandwidth.
1. Traffic Estimation (Queries Per Second - QPS)
This is often the first and most important calculation. It determines how many servers you need, the capacity of your load balancers, and the load on your databases. The process involves converting a high-level user metric (like Daily Active Users) into a peak request rate.
Back-Of-The-Envelope Estimation / Capacity Planning
This video provides a clear, step-by-step example of calculating peak QPS for Twitter.
Watch the segment from the inputs through the calculation. Observe how the presenter combines the three key inputs: DAU, usage per DAU, and a peak scaling factor. Then, continue watching from the simplification techniques to see how to use scientific notation and rounding to make the math manageable.
The general formula is:
2. Storage Estimation
Storage estimates drive decisions about databases, object storage, and long-term costs. For a frontend application, this can range from storing user-generated content like images and videos to caching data on the client.
Let's see how to estimate storage for multimedia content.
Back-Of-The-Envelope Estimation / Capacity Planning
This part of the video extends the Twitter example to calculate storage requirements for pictures and videos.
Watch the final example from the storage estimation. Note how the calculation incorporates the percentage of tweets with media, average file size, retention period (5 years), and a replication factor (3 copies).
The general formula for storage over a period is:
3. Bandwidth Estimation
Bandwidth, or data transfer, is especially critical for frontend performance. High bandwidth requirements can lead to slow page loads and high data costs for users. Estimating this helps justify the use of CDNs, compression, and efficient data formats.
The calculation is straightforward once you have the peak QPS and the average size of your API responses or assets.
Back of the Envelope Calculation: A Practical Guide
This section shows how to translate QPS and data size into a bandwidth requirement.
Read the section on Bandwidth Estimation. The key insight is to separate read and write traffic and to understand how bandwidth numbers directly lead to design decisions like implementing a CDN.
The formula is:
End-to-End Example: A Video Streaming Platform
Let's consolidate these concepts with a more complex, end-to-end example. Estimating the needs of a video streaming platform like YouTube involves calculating QPS for starting videos, storage for a massive library of content, and enormous bandwidth for streaming.
System Design Interview Vol. 1 Ch. 2 - Back-of-the-Envelope Estimation | Noah Tigner
This worked example is an excellent demonstration of applying the estimation framework to a complex, real-world system.
Carefully read the entire section Example: Video Streaming Platform. Pay special attention to the "QPS vs. Concurrent Streams" note. It highlights a crucial distinction: QPS measures the rate of initiation requests (driving API server scale), while concurrent streams measure active sessions (driving CDN and bandwidth costs). This is a sophisticated point that shows a deep understanding of system load.
Conclusion
In this lesson, we've demystified back-of-the-envelope estimation and equipped you with a structured process for applying it in an interview setting. You now have the tools to translate abstract user requirements into the concrete numbers that underpin a solid system design.
Here are the key takeaways:
- Purpose over Precision: The goal of estimation is to be directionally correct and ground your design, not to achieve perfect accuracy.
- A Structured Framework: Always follow a clear process: clarify the goal, state assumptions, decompose the problem, estimate the parts, and perform a sanity check.
- Core Estimations: Be prepared to estimate the three pillars of scale: Traffic (QPS), Storage, and Bandwidth.
- Connect to Design: Your estimations aren't just a math exercise. Use them to justify your architectural choices (e.g., "Our peak QPS of 11,500 necessitates a load balancer and a fleet of servers," or "The high bandwidth requirement of 4 Gbps makes a CDN essential.").
In our next lesson, we will begin to visualize the system that these numbers describe. You will learn how to diagram the high-level architecture of a client-server web application, using your estimations to inform the components you'll need and how they connect.