Module 08 // Interview playbookLesson 34 / 3420 min read
Back-of-the-envelope estimation
Back-of-the-envelope estimates are quick, rounded calculations of traffic, storage and bandwidth. They tell you whether a design needs one server or a thousand before you draw anything.
Think of it like this
Analogy
Before a road trip you don't need the exact fuel use to the milliliter. You think: about 600 km, the car does roughly 15 km per liter, so about 40 liters, which is one full tank plus a stop. Rough numbers like that are enough to decide whether you need to plan a fuel stop. System estimates work the same way.
The problem it solves
Designs built without numbers go wrong in both directions: sharded databases and ten microservices for an app with 50 requests per second, or a single database for something that will write a million rows a second. Interviewers expect a quick sanity check, and in real work it's how you size infrastructure and budgets before spending money.
A real example
Example
Sizing a photo app before launch
The plan is 1 million daily users, each uploading 2 photos a day, at about 500 KB each.
Storage: 1M × 2 × 500 KB = 1 TB a day. That's about 365 TB a year, or about 1.1 PB with 3 copies. Clearly object storage, not a database.
Uploads: 2 million a day ÷ about 100,000 seconds ≈ 20 a second. Tiny.
Views: if each user views 50 photos a day, that's 50 million ÷ 100,000 ≈ 500 views a second on average, and maybe 1,500 at the evening peak. So reads dominate, and a CDN in front of storage matters far more than a fast upload path.
Five minutes of rough maths has shown where the effort should go.
How it works
Handy numbers
| Fact | Rounded |
|---|---|
| Seconds in a day | 86,400 ≈ 10⁵ |
| Seconds in a month | ≈ 2.5 × 10⁶ |
| 1 million requests per day | ≈ 12 per second |
| 1 billion requests per day | ≈ 12,000 per second |
| 1 KB / 1 MB / 1 GB / 1 TB / 1 PB | 10³ / 10⁶ / 10⁹ / 10¹² / 10¹⁵ bytes |
| A short text post or chat message | 100 bytes to 1 KB with metadata |
| A compressed photo | 200 KB to 2 MB |
| One minute of HD video | 50–150 MB |
| Requests a single app server handles | hundreds to a few thousand per second (simple requests) |
| Reads a cache node handles | tens of thousands to 100,000+ per second |
Use powers of ten and round aggressively: the goal is the order of magnitude.
The method
- Users: daily active users (DAU).
- Traffic: actions per user per day × DAU ÷ 10⁵ = average QPS. Multiply by a peak factor (2–5×).
- Read/write split: reads per write, from the product (feeds are very read-heavy; chat is more balanced).
- Storage: writes per day × size × days kept × replicas.
- Bandwidth: QPS × response size, for both directions.
- Conclusions: how many servers, whether you need a cache, whether one database is enough, whether you need a CDN.
Try it with the calculator. Change one input and see which outputs move:
Worked example: a photo-sharing app
- 50 M DAU; 10% post one photo a day, which is 5 M uploads a day ≈ 60 uploads per second, about 180 at peak.
- Each user views 100 photos a day: 5 × 10⁹ views ÷ 10⁵ ≈ 50,000 reads per second, perhaps 150,000 at peak.
- Storage: 5 M × 2 MB = 10 TB a day, about 3.6 PB a year before extra resized copies and replication.
- Read bandwidth: 50,000 × 200 KB (a resized image) = 10 GB/s, which only a CDN can serve sensibly.
Conclusions: uploads are modest, so a few servers can take them; image delivery must go through a CDN with object storage behind it; metadata reads need caching; storage growth is the major cost to plan for.
Practice problems
Work these out yourself, then open the answers.
Interview questions
Try answering out loud first, then open the model answer.
Practice 1: A URL shortener creates 100 million links a month, with 100 redirects per link-creation. Estimate QPS and 5-year storage (500 bytes per link).
Model answer
Writes: 10⁸ ÷ 2.5 × 10⁶ s ≈ 40 per second. Reads: × 100 ≈ 4,000 per second average, maybe 10,000+ at peak. Storage: 10⁸ × 12 months × 5 years = 6 × 10⁹ links × 500 B = 3 TB, about 9 TB with three replicas. Conclusion: read-heavy and small. A cache absorbs most reads; a sharded key-value store handles storage easily (lesson 26).
Practice 2: A chat app has 200 million DAU sending 50 messages a day, 100 bytes each. Estimate message QPS and daily storage.
Model answer
Messages: 2 × 10⁸ × 50 = 10¹⁰ a day ÷ 10⁵ ≈ 100,000 per second average, perhaps 300,000 at peak. Storage: 10¹⁰ × 100 B = 10¹² B = 1 TB a day of text, around 3 TB with replicas, so about 1 PB a year. Conclusion: very high write rate, so you need a horizontally scalable, partitioned store and log (lesson 27); the volume is fine with wide-column storage and tiering of old messages.
Practice 3: A video site has 10 million viewers a day watching 30 minutes each at 4 Mbps. Estimate daily egress and peak bandwidth.
Model answer
Per viewer: 30 × 60 s × 4 Mb/s = 7,200 Mb = 900 MB. Daily: 10⁷ × 900 MB = 9 PB a day. Average bandwidth: 9 × 10¹⁵ B ÷ 10⁵ s ≈ 9 × 10¹⁰ B/s ≈ 720 Gbps; with a 3× evening peak, about 2 Tbps. Conclusion: only a large CDN can serve this; egress cost dominates, and codec efficiency directly cuts the bill (lesson 29).
Practice 4: A metrics system receives 1 million data points per second, 50 bytes each, kept for 30 days. How much storage, and can one database take the writes?
Model answer
Per day: 10⁶ × 50 B × 86,400 ≈ 4.3 × 10¹² B ≈ 4.3 TB a day; 30 days ≈ 130 TB, before compression (time-series databases often compress 5–10×) and replication. One million writes per second is well beyond a single relational database. Use a partitioned time-series or wide-column store, batch writes, and downsample older data.
Trade-offs
What you gain
- Catches designs that are wildly over- or under-built in minutes.
- Gives concrete reasons for components (“we need a CDN because 10 GB/s”).
- Turns vague requirements into numbers you can discuss with the interviewer.
What it costs you
- Inputs are guesses; small errors can multiply.
- Easy to spend too long chasing precision.
- Averages hide peaks; always apply a peak factor.
When not to use it
- Don't do detailed capacity planning in an interview; orders of magnitude are enough.
- For real budgets and launches, follow up estimates with load tests and the provider's pricing calculator.
In the cloud
Cost estimationEvery major cloud sells this as a managed service, so you configure it rather than build it.
AWS1
- AWS Pricing Calculator (opens vendor docs)
Build a cost estimate for an architecture before you deploy it.
Azure1
- Azure pricing calculator (opens vendor docs)
Estimate monthly costs for Azure services.
Google Cloud1
- Google Cloud Pricing Calculator (opens vendor docs)
Estimate costs for Google Cloud services.
Quiz
Pick an answer to see whether it’s right and why.
0 of 6 answered
Key terms
- QPS
- Queries (or requests) per second, the usual unit for load.
- Throughput
- How many requests a system can handle per unit of time, such as requests per second.
- Latency
- How long one request takes from start to finish, usually measured in milliseconds.
- Bandwidth
- How much data a link can carry per second, such as 1 Gbps.
- Replication
- Keeping copies of the same data on more than one machine.
Progress is saved in this browser only.