# Back-of-Envelope Estimation for System Design Interviews: The Maths in 30 Seconds (2026)
> Five numbers, four formulas and an October 2026 latency sheet are enough to size most interview systems in under a minute, including an AI feature. Worked examples show which numbers change the design.
*Source: https://www.infowok.com/back-of-envelope-estimation-primer/ · Sukhveer Kaur · Published October 17, 2026*
---
Twelve minutes into the round, the interviewer leans back: "Roughly how much storage will this need?" The candidate writes 86,400 on the board, starts multiplying it by 11.6, and the room goes quiet. Three minutes later there is a precise number, and no time left for the deep dive.
Estimation in a system design interview is a Fermi problem: "an estimation problem in physics or engineering education" ([Wikipedia](https://en.wikipedia.org/wiki/Fermi_problem)), applied to servers. Nobody checks your arithmetic to the decimal. The interviewer checks three things: are the assumptions stated, is the order of magnitude right, and did the number change a decision?
This lesson gives you the numbers and formulas to answer in thirty seconds, a 2026 latency sheet, and a way to size an AI feature. Figures were checked on October 17, 2026.
- [The system design interview framework](/system-design-interview-framework-2026/), lesson 1 of this course. Estimation slots into its high-level design and deep-dive steps.
- Comfort with powers of ten. No other maths.
When is a back-of-envelope estimate worth doing? Only when its answer can change a decision, such as one database or several.
- Estimate only when the answer can change the design.
- A day is about 100,000 seconds, so a million requests a day is about 12 per second.
- Every estimate is assumptions times arithmetic. Say the assumptions first.
- Latency in 2026 has four rungs: memory, SSD, zone, ocean. Each rung decides where data should live.
- For AI features, tokens and vectors usually decide more than server count.
Turn a traffic assumption into peak QPS, five-year storage and token volume in under a minute, and name the design decision each number drives.
## Five Numbers to Memorise
Almost every interview estimate is built from these. Learn them once and the rest is multiplication.
| Number | Exact | Use in the room |
|---|---|---|
| Seconds in a day | 86,400 | **~100,000** (10⁵) |
| Seconds in a month | ~2,592,000 | **~2.5 million** |
| 1 million requests/day | ~11.6/s | **~12/s** |
| Unit steps | KB → MB → GB → TB → PB | each step is ×1,000 |
| Peak factor | your assumption | state one, such as **×3** |
The peak factor is not a law of nature. It is an assumption you announce: "I'll assume the busiest hour runs at three times the average." Interviewers accept almost any reasonable factor as long as you say it out loud.
## Four Formulas
```text
avg QPS = users x actions per user / 100,000
peak QPS = avg QPS x peak factor
storage = items/day x bytes/item x days kept
bandwidth = QPS x bytes per response
```
Write them on the board in this order. Each one feeds a different decision. QPS decides how many servers and whether you need a cache. Storage decides whether one database is enough. Bandwidth rarely matters for text, and often matters for images or video.
## A Worked Example: The URL Shortener
Lesson 1 used a URL shortener with 100 million new links a month. Here is the full estimate with every assumption on the first lines.
```text
Assumptions: 100M new URLs/month, 100 reads per write,
500 bytes per row, peak = 3x, keep 5 years
Writes 100M / 2.5M s ≈ 40 /s peak ≈ 120 /s
Reads 40 x 100 ≈ 4,000 /s peak ≈ 12,000 /s
Storage 100M x 500 B ≈ 50 GB/month
x 12 x 5 ≈ 3 TB in 5 years
Codes 100M x 12 x 5 ≈ 6 billion URLs
62^6 (6 chars) ≈ 56.8 billion -> enough
Egress 4,000 /s x 500 B ≈ 2 MB/s -> not a concern
```
Now read the numbers for what they decide. **Reads outnumber writes a hundred to one, so reads shape the design**: a cache in front of the database earns its place. Storage of 3 TB over five years is worth mentioning but is no reason to shard on day one. A six-character code covers the whole five-year volume nine times over. Bandwidth is a non-issue. Four lines of arithmetic, four decisions.
"86,400, call it 100,000." Saying the rounding out loud shows the interviewer you know the exact figure and chose speed. It also saves you from long multiplication on a whiteboard.
## Latency in 2026: Four Rungs
Load numbers tell you how much work arrives. Latency numbers tell you where time goes, and therefore where data should live.
Before you read the table: how many times faster is a read from memory than a read from a fast SSD? Ten times? A thousand? Commit to a guess.
| Operation (as of October 2026) | Typical time |
|---|---|
| Main memory reference | ~100 ns |
| NVMe SSD 4K random read, one request at a time | ~30–90 µs |
| Round trip between availability zones in one region | under ~2 ms |
| Round trip, nearby regions (US East ↔ US East 2) | 8 ms |
| Round trip, US East ↔ US West | 69 ms |
| Round trip, US East ↔ Western Europe | 83 ms |
| Round trip, Central India ↔ Western Europe | 139 ms |
Sources for each row: memory has held near 100 ns for nearly two decades ([Colin Scott](https://colin-scott.github.io/personal_website/research/interactive_latency.html)). The SSD row is a lab measurement of current PCIe 5.0 enterprise drives, where the fastest answered a lone 4K read in about 30 µs and the rest of the group in 60 to 90 ([StorageReview](https://www.storagereview.com/best/enterprise-ssds)).
Microsoft targets inter-zone round trips under about 2 ms ([Microsoft Learn](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview)), and the region-to-region rows are its measured medians for the 30 days ending July 30, 2026 ([Microsoft Learn](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency)).
So the answer to the prediction: a memory read is roughly 300 to 900 times faster than an SSD read. An SSD read is in turn about 20 to 70 times faster than a hop to another zone, and a zone hop is tens of times faster than crossing an ocean. **Memorise the four rungs as 100 ns, 50 µs, 2 ms, 100 ms.** Each is a rounded midpoint, good enough for the board.
### What the Rungs Decide
In a design, each rung settles one kind of choice:
- **Cache in memory** when a hot read sits on the request path.
- **SSD-backed stores are fine** for most reads. The old advice to avoid disk came from spinning drives.
- **Replicate synchronously across zones**, since 2 ms is affordable on a write.
- **Never cross an ocean synchronously** on every request. Serve from a nearby region instead.
The famous "latency numbers every programmer should know" list traces back to Peter Norvig's 2002 figures ([Norvig](https://norvig.com/21-days.html)). Its disk rows describe spinning disks with millisecond seeks, and its network row assumes 1 Gbps links. In 2026 AWS's network-optimised instances offer up to 600 Gbps ([AWS](https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ec2-r8idn-r8idb/)). Use the classic table to understand the idea, not to quote values.
## Estimating an AI Feature
Many 2026 prompts include a model call: "design a support chatbot that answers from our help centre". The same four formulas apply, with two new units: **tokens** and **vectors**. Here is a worked estimate. Every input is an assumption you would state in the room.
```text
Assumptions: 50,000 help articles, 10 chunks each,
1,024-dim float32 embeddings,
200,000 questions/day, peak = 3x,
3,000 prompt + 300 answer tokens per question
Chunks 50,000 x 10 = 500,000
Vectors 500,000 x 1,024 x 4 B ≈ 2 GB
QPS 200,000 / 100,000 ≈ 2 /s peak ≈ 6 /s
Tokens 200,000 x 3,300 ≈ 660M tokens/day
Cost tokens/day x price -> check provider pricing
```
Read it for decisions, the same way as before:
- **2 GB of vectors fits in one machine's memory.** You do not need a distributed vector database for this size.
- **Six questions a second at peak is light load** for the web tier. The interesting numbers are elsewhere.
- **Tokens are the bill.** 660 million a day, almost all of it prompt. Multiply by your provider's current per-token price, which changes often, so look it up rather than memorising it. Retrieving fewer or shorter chunks cuts cost directly.
- **The model call dominates latency.** It is slower than every rung in the ladder, and it varies by model and answer length, so measure it and stream the answer to the user.
The [LLM system design interview guide](/llm-system-design-interview-2026/) takes this design further.
## Three Mistakes That Cost Minutes
- **Mixing bits and bytes.** Network links are quoted in bits per second, storage in bytes. Divide by eight: a 1 Gbps link moves about 125 MB per second, not 1 GB.
- **Forgetting copies.** Most databases keep more than one copy of each row for durability. If you assume three replicas, say so and triple the storage figure.
- **Switching time units mid-sum.** Convert everything to per-second or per-day before multiplying. Most whiteboard errors are a monthly number divided by seconds in a day.
## Try It: Size Pastebin
Use the Pastebin requirements from lesson 1's drill. Assume **1 million new pastes a day**, an average paste of **10 KB**, **10 reads per write**, a peak factor of **×3**, and five years of retention. Work out:
1. Average and peak write QPS.
2. Average and peak read QPS.
3. Storage per day and over five years.
4. One design decision the storage number forces.
1 million a day is the anchor from the table: about 12 per second. Then compare the five-year storage figure with how much the metadata alone would take at, say, 200 bytes per paste.
```text
Writes 1M / 100,000 s ≈ 10 /s peak ≈ 30 /s
Reads 10 x 10 ≈ 100 /s peak ≈ 300 /s
Storage 1M x 10 KB ≈ 10 GB/day
x 365 x 5 ≈ 18 TB in 5 years
Metadata 1M x 200 B ≈ 200 MB/day ≈ 73 GB/year
```
Decision: the paste bodies dominate storage, the metadata is small. Put the text in object storage and keep only the metadata (code, owner, expiry, object key) in the database. Load is modest at a few hundred reads per second at peak, so the interesting conversation is about storage and expiry, not about servers.
Your figures can differ by a factor of two. They are right if the assumptions are stated and the decision follows from them.
A common slip is to compute numbers and then never use them. After each figure, finish the sentence out loud: "...so reads dominate, and I'll put a cache in front of the database." An estimate that ends without a "so" scores nothing.
20M x 5 = 100M requests a day. 100M / 100,000 ≈ 1,000 requests per second on average, and about 3,000 at a ×3 peak.
The ocean rung, tens to hundreds of milliseconds per request. Replicate the profile data to the serving region, or cache it in memory there.
Vectors grow a hundredfold to about 200 GB, which no longer fits comfortably in one machine's memory, so a sharded or disk-backed vector index becomes worth discussing. Token cost does not change, because it depends on questions, not on articles.
Tomorrow, pick any app on your phone, guess its daily users, and size its writes, storage and peak QPS on paper in sixty seconds. Then do it again for one AI feature it has. Repetition with new numbers is what makes the formulas automatic.
## In One Picture
```text
Day = 10^5 s 1M/day ≈ 12/s peak = x3
QPS -> servers, cache? Storage -> one DB?
Ladder: 100 ns · 50 µs · 2 ms · 100 ms
AI: tokens/day x price vectors = n x dims x 4 B
Every number ends with "so..."
```
Five numbers, four formulas, four rungs and one habit cover most interview estimates. The habit matters most: state the assumption, round hard, and end every figure with what it means for the design.
**Which estimate trips you up most: QPS, storage or tokens?** Tell us in the comments.
- **Back to the framework:** [the six steps](/system-design-interview-framework-2026/) show where estimation fits in the round.
- **Where the numbers lead:** [caching strategies](/caching-strategies/) covers the cache that most read-heavy estimates point to.