Back-of-the-Envelope Calculations for System Design Interviews
Learn a repeatable estimation method for system design interviews, with worked traffic, storage, bandwidth, cache, and capacity examples.
In this article
In a system design interview, “this should scale” is not a capacity plan. A back-of-the-envelope estimate turns a few product assumptions into rough traffic, storage, bandwidth, and compute numbers. Those numbers help you decide which parts of the architecture deserve attention before drawing boxes.
The goal is not to predict production to the last decimal place. It is to make your assumptions visible, do arithmetic that is directionally sound, and use the result to explain a design choice.
What a back-of-the-envelope estimate is
A back-of-the-envelope calculation is a fast, transparent approximation of the scale a system must handle. It starts with a workload description—users, actions, payloads, and retention—and derives quantities an architecture can act on:
- Requests or events per second, on average and at peak.
- Read and write rates, including work triggered by one user action.
- Data created each day and retained over time.
- Network bandwidth and cache or database load.
- A first estimate of concurrency or service instances.
It is not a substitute for load tests, benchmarks, a detailed data model, or an SLO. It is also not a contest to memorize hardware trivia. If an estimate depends on a server handling a certain number of requests per second, say that it is a measured or hypothetical input and explain how you would validate it.
The diagram is a reasoning path, not a one-way checklist: a capacity concern may make you revisit a product assumption or separate one workload from another.
A repeatable method
1. Clarify the workload
Name the product actions the system serves and what “one request” means. One screen view might call several APIs; one upload might create metadata, image variants, and events. Define whether you are sizing the API, the whole system, or a specific dependency.
2. Turn users into operations
Use concurrent or daily active users as appropriate, then multiply by an explicit activity rate. Split reads, writes, uploads, fanout, and background work if they stress different resources.
3. Convert average load into a peak scenario
Divide daily work by the number of seconds in a day, then apply a justified peak-to-average factor. If you do not know the real traffic shape, label the multiplier as an assumption and test a range.
4. Attach bytes and retention
Estimate request and response sizes, record sizes, and how long data stays. Separate metadata from media, and include derived copies or indexes only when the assumption is clear.
5. Compare demand with capacity
Translate the workload into database calls, network bandwidth, concurrency, or benchmarked instance throughput. Include cache misses, retries, fanout, and failure headroom where they apply.
6. Identify the uncertainty that matters
Ask which assumption could change the design. If doubling average payload barely changes the architecture but a hot-key spike overwhelms the database, focus the discussion on traffic concentration and admission control.
Keep a few conversion anchors handy
These are decimal, round-number conversions. Keep units consistent throughout a calculation; for storage systems that report binary units, distinguish KiB/GiB from KB/GB.
| Quantity | Quick conversion | Useful mental check |
|---|---|---|
| One day | 86,400 seconds | About 100,000 seconds for very rough math |
| 1 million operations per day | 11.6 operations/second | Roughly 12/s |
| 1 billion operations per day | 11,574 operations/second | Roughly 12k/s |
| 1 billion records at 1 KB each | 1 TB | Before indexes, copies, and overhead |
| 1 million objects at 1 MB each | 1 TB | Decimal MB and TB |
| 1 byte | 8 bits | Convert bytes per second to bits per second |
Example 1: Turn daily activity into peak RPS
Suppose a social product has 50 million daily active users, and each active user causes 20 API requests per day on average. This is a workload assumption, not a statement that every person behaves identically.
Divide by 86,400 seconds:
Now assume, for planning, that the busy period is four times the average:
Here is the arithmetic as a visual flow. It shows how an assumption about peakiness affects the output; it does not claim that four is the correct peak multiplier for every service.
- Total request volume
- 1B/day
- 50M DAU × 20 requests per user per day.
- Average rate
- 11.6k/s
- One billion requests divided by 86,400 seconds.
- Peak scenario
- 46.4k/s
- Average multiplied by an explicit 4× planning assumption.
If reads are 80% and writes 20% during the peak as well, that is about 37,000 read requests/s and 9,300 writes/s. Real read and write patterns may peak at different times, so do not assume their daily ratios automatically describe the busiest minute.
Check what each API request does next. A request that fans out to five storage reads is not one database read. A post that is delivered to 200 followers may create asynchronous work proportional to the fanout. Estimate those downstream operations separately instead of hiding them inside “RPS.”
Example 2: Estimate storage growth for images
Imagine a media service accepts 500,000 images per day. Keep one original at 1.5 MB and generate two display variants at 300 KB and 80 KB. The retained image data per upload is approximately:
That gives:
- Per day: 500,000 × 1.88 MB = 940,000 MB, or about 0.94 TB/day.
- Per year: 0.94 TB × 365 ≈ 343 TB/year before replicas, backups, or metadata.
- With three durable copies: roughly 1 PB/year of image bytes, before those additional costs.
The estimate changes if images are compressed differently, variants are regenerated rather than retained, old originals expire, or the storage layer has a different replication policy. Track metadata separately: a 1 KB metadata row for every upload adds about 0.5 GB/day at this volume, before indexes and database overhead. Do not multiply the image estimate by a replication factor and then silently add another factor for the same copies.
Example 3: Translate requests into bandwidth and capacity
Return to the 46,400 requests/second peak scenario. Suppose the average response body is 20 KB. At the application boundary, estimated outbound traffic is:
Convert bytes to bits: about 7.4 Gbit/s of response-body traffic. This excludes protocol overhead, response-size variance, and other traffic. A CDN may shift cacheable bytes away from the application origin, but it does not make user-facing delivery bandwidth disappear.
Now assume 80% of peak requests are reads and that a cache gets a 95% hit rate for those reads. The origin still sees approximately:
That is a useful reduction, but only under the stated workload and hit-rate assumptions. Writes, refreshes, misses on cold keys, and cache failure still need capacity and a deliberate fallback policy. For a deeper cache design, see the guide to caching strategies.
Estimate concurrency without pretending it is server count
Little’s Law relates average in-flight work to throughput and average time in the system:
If the service averages 200 ms end-to-end at 46,400 requests/second, that is about 9,300 requests in flight. This is concurrency, not a count of threads, connections, or machines. Queueing and latency percentiles can make the peak experience worse than this average suggests.
For an intentionally hypothetical fleet calculation, suppose a load test shows one instance sustains 600 requests/second at the chosen latency target. Plan to use 70% of that measured rate, or 420 requests/second per instance:
That covers throughput only under the benchmark’s workload. If you also want the same load to fit after losing one instance, plan for 112 in this simplified example. Losing an entire availability zone, skewed work, deployments, and autoscaling delay require a different headroom calculation. The measured per-instance rate must come from the actual service and payload mix—not a universal “requests per server” rule.
How estimates change the architecture
An estimate earns its place when it leads to a design decision. For the examples above, plausible consequences are:
| Estimate or risk | Design question it raises |
|---|---|
| Tens of thousands of peak reads per second | Can a cache or CDN serve repeatable reads, and what is the miss path? |
| Thousands of writes per second | Which writes must be synchronous, and can independent work be queued? |
| About 1 PB/year of image copies | Should object storage hold media while the database holds metadata and references? |
| Several Gbit/s of response traffic | Which responses are cacheable, and where should delivery happen? |
| High in-flight concurrency | Do connection pools, queues, and downstream timeouts have appropriate bounds? |
| Traffic concentrated on one popular object | How will hot keys, request coalescing, or replication behave? |
These are prompts for design, not automatic prescriptions. For example, putting a queue in front of a write does not work if the product must confirm a transaction synchronously. A cache helps repeated reads, but it cannot remove an invariant that must be checked against an authoritative store.
Make uncertainty part of the answer
Use a low, base, and high scenario for assumptions that could change the result. A rough range is more honest and often more useful than a precise-looking point estimate.
| Input | Base assumption | Sensitivity to check |
|---|---|---|
| Activity per user | 20 requests/day | Does a heavy cohort make it 2× or 5× higher? |
| Peak factor | 4× average | Is traffic bursty by time zone, launch, or notification? |
| Response body | 20 KB | Are large responses or media served on this same path? |
| Cache hit rate | 95% on reads | What happens during cold start or cache outage? |
| Instance throughput | 600/s at the latency target | Does the representative request mix sustain it under failure? |
Watch for these common traps:
- Sizing from registered accounts. Most are not necessarily active at once. Use the metric that matches the product behavior.
- Using average RPS as peak capacity. Keep average and peak scenarios separate.
- Treating a user action as one backend operation. Include API fanout, retries, and background side effects.
- Mixing bytes and bits, or MB and MiB. Carry units through every multiplication and conversion.
- Ignoring skew. Averages conceal a single hot tenant, key, event, or geography.
- Applying replication twice. State whether the record size already includes copies or derived assets.
- Calling a benchmark an estimate. Label unmeasured throughput as a hypothesis and specify the test that would replace it.
- Forgetting failures. A system should have an explicit behavior for cache loss, a slow database, retry storms, and one overloaded partition.
A concise way to present the math in an interview
You do not need to recite every number. Say the assumptions, show the calculation that affects a decision, and invite correction:
“I’ll size the API from daily active users. If 50 million users make 20 API calls a day, that is 1 billion calls a day, or about 12,000 requests per second on average. I’ll use a 4× peak scenario for now, so roughly 46,000 requests per second. I’m assuming 80% reads; I’d validate the peak and request mix with traffic data. That points me to check the cache-miss load and bandwidth before choosing the database and fleet size.”
If the interviewer changes an assumption, update the result rather than defending the old number. Doubling activity doubles the request estimate; halving the cache hit rate roughly doubles read misses, all else equal. That ability to reason about sensitivity is more valuable than memorizing a single answer.
The takeaway
Back-of-the-envelope calculations connect product behavior to architecture. Start with a clearly scoped workload, convert activity into average and peak operations, multiply by realistic bytes and work, account for retention and failure headroom, then ask which assumption could change the design. Keep the math visible, the units consistent, and the confidence level honest.