Back-of-the-Envelope Estimation for System Design (2026)

Back-of-the-Envelope Estimation for System Design Interviews

Back-of-the-envelope estimation turns vague phrases such as “a large application” into numbers that guide an architecture. Interviewers are not testing whether you can multiply perfectly under pressure. They want to see whether you can make reasonable assumptions, find the likely bottleneck, and connect the result to a design decision.

The best estimates are short and useful. If a calculation does not change your storage, partitioning, caching, bandwidth, or availability plan, skip it. This guide gives you a reusable method, the handful of numbers worth memorizing, and a worked example you can explain at the whiteboard.

Why Does Capacity Estimation Matter?

Imagine that someone asks you to design a parking garage but does not say whether it serves an apartment building or an international airport. Both need entrances, exits, and spaces, but the scale changes every important choice. A system design prompt has the same ambiguity.

Estimation helps you answer practical questions:

• Can one service instance handle the traffic, or do we need horizontal scaling?
• Can one database store the data, or will it need partitioning?
• Will reads overwhelm storage unless we add caching or replicas?
• Is network bandwidth large enough to require a CDN or compression?
• How many partitions, workers, or machines should the first design support?

Numbers also prevent accidental over-engineering. A system with 20 writes per second probably does not need a globally partitioned event pipeline on day one. A system with 200,000 peak writes per second probably cannot rely on one relational primary without a careful sharding or buffering story.

Which Numbers Should You Memorize?

You only need a compact mental toolbox. Round aggressively because interview estimates are about order of magnitude, not accounting precision.

• Seconds per day: about 100,000. The exact value is 86,400, but 100,000 makes mental division easy.
• Storage units: 1 KB is about 1,000 bytes, 1 MB is about 1,000 KB, 1 GB is about 1,000 MB, and 1 TB is about 1,000 GB.
• Typical text record: hundreds of bytes to a few KB, depending on metadata.
• Thumbnail image: tens to hundreds of KB. A full photo may be several MB.
• Replication: three copies means roughly three times raw storage before indexes and overhead.
• Peak traffic: often three to ten times average, depending on geography and synchronized events.
• Cache sizing: active data is usually far smaller than all historical data; estimate the hot set separately.

State every assumption. “I will assume an average post record of 2 KB excluding media” is better than presenting 2 KB as a universal fact. If the interviewer prefers a different value, update the math and continue.

How to Estimate QPS, Storage, and Bandwidth

Requests per second

Start with daily actions. If 50 million daily users each load the home screen 10 times, that is 500 million reads per day. Divide by 100,000 seconds to get about 5,000 average reads per second. Apply a five-times peak factor and design for about 25,000 peak reads per second.

Keep reads and writes separate. A read-heavy product may have 100 reads for every write, which points toward caching and read replicas. The article on caching strategies for system performance explains how that ratio changes the read path.

Storage growth

Multiply new objects per day by average object size. If users create 10 million posts per day and each post plus metadata averages 2 KB, daily raw growth is 20 GB. That is about 7.3 TB per year. With three replicas, indexes, and operational headroom, you might plan for 25 to 35 TB per year rather than quoting 7.3 TB as the final capacity.

Bandwidth

Bandwidth is object size multiplied by requests per second. If an API returns 20 KB and serves 25,000 peak responses per second, it sends roughly 500 MB per second. That is about 4 gigabits per second before protocol overhead. For large media, bandwidth and edge delivery can matter more than database capacity.

Cache memory

Estimate the hot working set, not the full history. If 5 million active users each need a 20 KB cached first page, that is 100 GB of raw cached data. Add key overhead, replication, and headroom; a practical cluster might target 250 to 350 GB.

A Worked Example: Estimate a URL Shortener

Suppose the interviewer asks for a global URL shortener. After clarifying the scope, you assume 100 million new short links per month, a 100-to-1 read-to-write ratio, five years of retention, and an average stored record of 1 KB including the short code, destination URL, timestamps, and metadata.

1. Write QPS: 100 million writes per month is roughly 3.3 million per day. Divide by 100,000 to get about 33 average writes per second. At a five-times peak, design for roughly 165 writes per second.
2. Read QPS: At a 100-to-1 ratio, average redirects are about 3,300 per second and peak redirects about 16,500 per second.
3. Raw storage: 100 million records times 1 KB is about 100 GB per month, or 1.2 TB per year. Five years is 6 TB raw.
4. Replicated storage: Three copies make that 18 TB, and indexes plus headroom may move the capacity target toward 25 TB.
5. Bandwidth: Redirect responses are tiny, so bandwidth is not the main bottleneck. Read latency and cache hit rate matter more.
6. Design consequence: The write rate is modest, but the read path is much busier and latency sensitive. Cache popular code-to-URL mappings, replicate durable storage, and partition by a stable short-code hash when one node is no longer enough.

This example shows why estimates need conclusions. The important observation is not “25 TB.” It is that reads dominate writes, the record is small, and popular links are likely to be highly skewed. Those facts justify a cache and a partitioning plan more directly than the raw arithmetic does.

If the cache cluster grows over time, consistent hashing can minimize remapping when servers join or leave. If the database stores multiple copies, review database replication and replication lag so availability does not silently weaken correctness.

Want to master this with video lessons and real case studies? This topic is covered in depth in my Udemy course System Design Fundamentals for Interviews — 5.5 hours, rated 4.8★, built from real interview questions.

How to Turn Estimates Into Architecture Decisions

After each calculation, say “therefore” and name the design consequence. This simple habit keeps estimation from becoming a disconnected math exercise.

• Peak QPS is higher than one instance can serve; therefore use stateless services behind a load balancer and plan for horizontal autoscaling.
• Read traffic is much higher than write traffic; therefore cache hot data and consider read replicas.
• One year of storage exceeds a comfortable single-node size; therefore define a partition key and a rebalancing strategy.
• Media bandwidth dominates; therefore store blobs outside the database and deliver them through a CDN.
• Writes arrive in bursts; therefore buffer work with a durable queue and make consumers idempotent.
• One key can become extremely popular; therefore avoid a partition plan that sends all work for that key to one overloaded node.

Use ranges when uncertainty is large. If an image could be 200 KB to 2 MB, calculate both ends and explain which part of the design changes. Sensitivity analysis is often more convincing than pretending one guessed value is exact.

How to Talk About Estimation in an Interview

Here is a 30-second answer you can memorize:

“I will estimate only the numbers that affect the architecture. I will start with daily active users and actions per user, convert them to average and peak read and write QPS, then estimate storage growth and bandwidth where object size matters. I will state round assumptions, add replication and headroom, and finish every calculation with the design consequence, such as caching, partitioning, a CDN, or queue capacity. I am looking for the right order of magnitude, not false precision.”

Common estimation mistakes

• Using monthly active users as though every user is active every day.
• Calculating average QPS but forgetting peak traffic.
• Combining reads and writes even when their paths and costs differ.
• Counting raw data but forgetting replicas, indexes, metadata, and headroom.
• Estimating every possible metric without linking the answer to a decision.
• Doing silent arithmetic instead of letting the interviewer follow and correct assumptions.

If you make a math mistake, correct it and continue. Interviewers care more about a calm, transparent process than a perfectly memorized number.

Key Takeaways

• Estimate the bottleneck, not every metric available.
• Use round, stated assumptions and calculate average plus peak load.
• Separate reads, writes, storage, bandwidth, and the hot cache working set.
• Add replication, indexes, and headroom before turning raw data into capacity.
• Finish every estimate with the architecture decision it supports.

Next Steps

Use these calculations inside the step-by-step system design interview framework. Pick one case study, write down five assumptions, estimate peak QPS and one capacity bottleneck, then explain which component your numbers force you to add.