What is Back-of-the-Envelope Estimation?
Learn back-of-the-envelope estimation for system design interviews: estimating QPS, storage, and bandwidth from simple assumptions.
Expected Interview Answer
Back-of-the-envelope estimation is the practice of using rough, order-of-magnitude arithmetic (users, QPS, storage, bandwidth) to size a system design before writing any code, so architectural decisions are grounded in realistic scale rather than guesswork.
It starts from a small set of assumptions such as daily active users, requests per user, and average payload size, then chains simple multiplications to derive queries per second, peak load, storage growth per year, and bandwidth needs. The goal is not precision but the correct order of magnitude, since a system built for a thousand requests per second looks very different from one built for a million. Interviewers use this exercise to see whether a candidate can translate vague requirements into concrete numbers that drive real decisions, like whether to shard a database or add a CDN. Common reference numbers worth memorizing include typical read/write ratios, that a day has about 86,400 seconds, and that a single well-provisioned server can often handle a few thousand QPS for simple requests.
- Turns vague requirements into concrete numbers that guide architecture
- Reveals early whether a single server or a distributed system is needed
- Surfaces the dominant bottleneck (storage, bandwidth, or compute) quickly
- Builds interviewer confidence that design choices are scale-aware
AI Mentor Explanation
Back-of-the-envelope estimation is like a captain quickly working out required run rate from overs remaining and target score before setting a field, without needing ball-by-ball precision. A rough mental calculation — twelve overs left, seventy runs needed, so just under six an over — is enough to decide whether to attack or defend, exactly like estimating QPS from daily users is enough to decide the architecture. The captain does not need to model every possible delivery outcome, only the order of magnitude of pace required. That quick, assumption-driven arithmetic before committing to a strategy mirrors capacity estimation before a system design.
Step-by-Step Explanation
Step 1
State assumptions explicitly
Write down DAU, requests per user, and average payload size before calculating anything.
Step 2
Derive QPS
Multiply requests per user by DAU and divide by seconds in a day (about 86,400) to get average QPS, then estimate a peak multiplier.
Step 3
Derive storage and bandwidth
Multiply payload size by write volume per day, then project over a year to see growth trajectory.
Step 4
Identify the bottleneck
Compare the numbers against known single-server capabilities to decide if sharding, caching, or a CDN is needed.
What Interviewer Expects
- Stating clear, reasonable assumptions before calculating
- Deriving QPS, storage, and bandwidth from those assumptions
- Recognizing that precision matters far less than order of magnitude
- Using the numbers to justify concrete design decisions
Common Mistakes
- Jumping into architecture without estimating scale first
- Chasing decimal precision instead of order of magnitude
- Forgetting peak-to-average traffic ratios
- Never connecting the numbers back to an actual design decision
Best Answer (HR Friendly)
“Back-of-the-envelope estimation means doing quick, rough math on things like users, requests per second, and storage growth before designing a system, so the architecture is based on realistic scale instead of guesswork. It is less about getting an exact number and more about knowing whether you are dealing with thousands or millions of anything, since that changes the whole design.”
Code Example
const dailyActiveUsers = 5_000_000;
const requestsPerUserPerDay = 20;
const avgPayloadBytes = 2_000;
const dailyRequests = dailyActiveUsers * requestsPerUserPerDay;
const avgQps = dailyRequests / 86_400;
const peakQps = avgQps * 3; // assume 3x peak-to-average ratio
const dailyStorageBytes = dailyRequests * avgPayloadBytes;
const yearlyStorageGB = (dailyStorageBytes * 365) / 1e9;
console.log({ avgQps: Math.round(avgQps), peakQps: Math.round(peakQps), yearlyStorageGB: Math.round(yearlyStorageGB) });Follow-up Questions
- How would you estimate the peak-to-average traffic ratio for a social app?
- How does back-of-the-envelope estimation change your caching strategy?
- What reference numbers should every engineer memorize for these estimates?
- How would you validate an estimate once real production traffic is available?
MCQ Practice
1. What is the primary goal of back-of-the-envelope estimation in system design?
The exercise is about scale awareness — knowing thousands versus millions — not precise figures.
2. Roughly how many seconds are in a day, a number commonly used in these estimates?
A day has 86,400 seconds, a key constant for converting daily volume into average QPS.
3. Why is a peak-to-average traffic multiplier applied in these estimates?
Traffic clusters around peak hours, so average QPS understates the load the system must actually handle.
Flash Cards
What is back-of-the-envelope estimation? — Rough, order-of-magnitude math on scale (users, QPS, storage) done before designing a system.
Why order of magnitude, not precision? — Because it is the scale (thousands vs. millions) that changes the architecture, not exact figures.
Typical first inputs? — Daily active users, requests per user, and average payload size.
Why apply a peak multiplier? — Traffic is not flat across the day, so peak QPS is higher than average QPS.