Back-of-the-Envelope Estimates
Why estimate when you could skip it
Imagine you're planning a cookout with friends. Nobody counts every hot dog, but someone does a quick estimate: "there are eight of us, everyone eats about three, so we'll grab three packs." Being off by a couple of hot dogs is no big deal. Buying one pack — or twenty — is.
In a System Design interview, back-of-the-envelope estimates serve the same purpose. Nobody asks you to guess the exact number. What matters is the order of magnitude: 100 requests per second or 100,000? The architecture depends on it. A hundred can be handled by a single server with PostgreSQL. A hundred thousand needs sharding, caches and queues.
The main rule: round boldly. 86,400 is 10⁵. 3.7 is 4. The interviewer is grading your reasoning, not your arithmetic.
Cheat sheet: numbers worth remembering
Time
| What | Approximation |
|---|---|
| Seconds in a day | 86,400 ≈ 10⁵ |
| Seconds in a year | ≈ 3·10⁷ |
| Days in 5 years | ≈ 2,000 (1,825, to be exact) |
Latency (orders of magnitude, not exact values)
| Operation | Time |
|---|---|
| Read from memory (RAM) | ~100 ns |
| Random read from SSD | ~100 µs |
| HDD seek | ~10 ms |
| Round trip within a data center | ~0.5 ms |
| Intercontinental request (Europe ↔ US) | ~100–150 ms |
Two takeaways for the interview. Memory is roughly 1,000 times faster than SSD, so hot data lives in a cache. A request across the ocean eats the whole latency budget, so you need a CDN and regional data centers.
Sizes
| What | Size |
|---|---|
| ASCII character / Greek or Cyrillic letter in UTF-8 | 1 B / 2 B |
int64, timestamp |
8 B |
| UUID (binary / as a string) | 16 B / 36 B |
| Short text post with metadata | ~1 KB |
| Compressed photo | ~200 KB – 2 MB |
| One minute of 720p video | ~10–50 MB |
The one-minute formula
Every estimate follows the same chain:
- Daily active users (DAU) × actions per user = actions per day.
- Actions per day ÷ 10⁵ = average RPS.
- Average RPS × peak factor = peak RPS.
- Writes per day × record size = storage growth per day. Multiply by the retention period and by replication.
- Requests × response size = traffic.
Example: a post feed for 10M daily users
State your assumptions out loud:
- DAU = 10⁷;
- each user views 20 posts and publishes 1 post a day;
- a post weighs ~1 KB (text + UUID + author + timestamp);
- 10% of posts have a photo of ~200 KB.
Load
| Metric | Calculation | Result |
|---|---|---|
| Reads per day | 10⁷ × 20 | 2·10⁸ |
| Average read RPS | 2·10⁸ / 10⁵ | ~2,000 |
| Writes per day | 10⁷ × 1 | 10⁷ |
| Average write RPS | 10⁷ / 10⁵ | ~100 |
| Read : write ratio | 2,000 / 100 | 20 : 1 |
Storage for 5 years
| What | Calculation | Result |
|---|---|---|
| Text per day | 10⁷ × 1 KB | 10 GB |
| Photos per day | 10⁶ × 200 KB | 200 GB |
| Text over 5 years | 10 GB × 2,000 | ~20 TB |
| Photos over 5 years | 200 GB × 2,000 | ~400 TB |
| With 3× replication | 420 TB × 3 | ~1.3 PB |
Outbound traffic
| What | Calculation | Result |
|---|---|---|
| Average response per view | 1 KB + 0.1 × 200 KB | ~21 KB |
| Traffic per day | 2·10⁸ × 21 KB | ~4 TB |
| Average bandwidth | 4 TB / 10⁵ s | ~40 MB/s ≈ 0.3 Gbps |
Now the numbers point to the architecture. Photos are 95% of the volume and traffic, so they belong in object storage behind a CDN. The text (20 TB) fits in a sharded database. There are 20 times more reads than writes, so a cache will pay off.
Peak ≠ average
Average RPS is what you get by spreading the day out evenly. Real load looks like a hump: quiet at night, and in the evening everyone is on their phone.
How to talk about the peak factor:
- ×2–3 — a normal daily peak for a consumer service;
- ×5–10 — sales like Black Friday, New Year's Eve, a push notification to the whole user base, the Super Bowl.
In our example, peak reads come to 2,000 × 3 ≈ 6,000 RPS, and with headroom for events we plan for ~10–20K RPS. Design for the peak, not the average. The average is for estimating storage and cost.
How it sounds in an interview
"Let's take 10 million DAU, each reading 20 posts and writing one. That's 2·10⁸ reads a day; divide by 10⁵ seconds and we get about 2,000 RPS on average, ×3 at peak — 6,000. Writes are about 100 RPS. A 20:1 skew toward reads, so we need a cache. For storage, photos take 400 TB over 5 years versus 20 TB of text, so I'll put photos in S3 behind a CDN."
One minute like that shows you think in numbers, not buzzwords. Be sure to name the trade-offs of your assumptions: "if it's video instead of photos, the volume grows by an order of magnitude, and then transcoding and storage cost become the main concerns."
Common mistakes
- Exact arithmetic instead of orders of magnitude. Dividing by 86,400 in your head is a waste of time.
- Silent assumptions. Say each one out loud: the interviewer may correct you, and that's fine.
- Forgetting replication and indexes. The real size on disk is 2–3 times the "raw" data.
- Designing for the average. A system built for 2,000 RPS will fall over in the evening.
- Numbers for the sake of numbers. Once you've computed something, draw a conclusion: "so we need a cache / sharding / a CDN." Otherwise the estimate isn't working for you.
Practice on three services: a messenger, a URL shortener, a video hosting site. By the third one, the chain "DAU → RPS → peak → storage → traffic" will come out on its own.