Back-of-the-Envelope Estimation for System Design Interviews
Estimates exist to justify design decisions. Nobody cares whether you say 1,157 or 1,200 requests per second. They care whether you notice that the number means "one database is fine" or "we need to shard".
You only need a handful of numbers and two habits: round aggressively, and say what each result implies.
The numbers worth memorising
Time
- 1 day = 86,400 seconds ≈ 10⁵ seconds (round up; it keeps the maths easy and errs on the safe side).
- 1 month ≈ 2.5 million seconds. 1 year ≈ 3 × 10⁷ seconds.
Requests
- 1 million per day ≈ 12 per second on average.
- 100 million per day ≈ 1,200 per second.
- Peak is often assumed at 2–3x the average unless the interviewer gives you a profile.
Sizes
| Thing | Rough size |
|---|---|
| ID (64-bit integer) | 8 bytes |
| UUID | 16 bytes |
| Timestamp | 8 bytes |
| Short text (tweet-sized) | ~300 bytes with metadata |
| Image thumbnail | ~10–50 KB |
| Photo | ~200 KB – 2 MB |
Latency orders of magnitude
| Operation | Roughly |
|---|---|
| Read from memory | ~100 ns |
| Random read from SSD | ~100 µs |
| Round trip within a datacenter | ~0.5 ms |
| Disk seek (spinning disk) | ~10 ms |
| Round trip across continents | ~100–150 ms |
The exact values move with hardware. What matters is the ratios: memory is about a thousand times faster than SSD, and a cross-continent round trip costs as much as hundreds of in-datacenter calls.
The four estimates you'll actually do
1. Traffic (QPS)
daily active users × actions per user per day ÷ 10⁵
Example: 50 million daily users, each loading their feed 10 times a day → 5 × 10⁸ ÷ 10⁵ = 5,000 reads per second, ~15,000 at peak. Posting: 1 post per user per day → 500 writes per second. Read/write ratio 10:1, so the read path gets the caching effort.
2. Storage
writes per day × size per write × 365 × years
Example: 50 million posts a day × 300 bytes = 15 GB a day ≈ 5.5 TB a year of text. Add media separately: if 10% of posts carry a 500 KB image, that's 2.5 TB per day, about 900 TB a year. Media dominates, so it goes to object storage behind a CDN, not the database.
3. Bandwidth
QPS × response size
5,000 feed reads per second × 50 KB per response = 250 MB/s of egress. That's a hint that you want a CDN and pagination, not a bigger server.
4. Servers or shards (only if asked)
If one machine comfortably handles a few thousand simple requests per second (state your assumption), 15,000 peak reads → a handful of stateless app servers, plus headroom. For storage, divide total data by what one node should hold to get a shard count.
Saying what the numbers mean
Every estimate should end with a sentence that changes the design:
- "500 writes per second fits on one primary database with room to spare."
- "5.5 TB a year of text means we'll need to partition within a couple of years; I'll pick the partition key now."
- "Reads are 10x writes, so I'll cache feeds and precompute them for active users."
Mistakes interviewers notice
- False precision. "1,157.4 QPS" signals you're calculating, not thinking.
- Forgetting peak. Systems fall over at peak, not at the average.
- Mixing units. Bits versus bytes, per day versus per second. Write units on every line.
- Estimating and moving on. An estimate that doesn't change a decision was wasted time.
- Spending ten minutes here. Three to four minutes is plenty in a 45-minute interview.
Practise estimates inside real questions. Prepd's system design questions are broken into steps with written feedback on each answer, so you can practise sizing a system as part of a real design rather than in isolation. The first two drills below are free, no sign-up needed.