Back-of-Envelope Estimation
Before you touch architecture, you need numbers. Learn the mental math that turns vague requirements into concrete scale targets — the skill interviewers test before everything else.
What you will learn
- Memorise the latency and storage numbers that underpin every estimate
- Convert daily active users into QPS in under 60 seconds
- Estimate storage and bandwidth requirements from first principles
- Work through a complete capacity estimate for a real system design scenario
Back-of-Envelope Estimation
Before you open a whiteboard in a system design interview, the interviewer wants to see one thing first: can you reason about scale?
Back-of-envelope estimation is the skill of deriving approximate numbers — requests per second, storage per year, bandwidth per day — from a small set of inputs. The goal is not precision. The goal is to establish whether you are designing for 100 QPS or 100,000 QPS, because those require completely different architectures.
Interviewers use this to separate candidates who state requirements ("the system handles 10 million users") from candidates who understand what that means at the infrastructure level.
1. Numbers Worth Memorising
You cannot estimate without reference points. These are the numbers experienced engineers carry in their heads.
Latency Reference Table
| Operation | Approximate Latency |
|---|---|
| L1 cache read | 1 ns |
| L2 cache read | 10 ns |
| RAM read | 100 ns |
| SSD random read | 0.1 ms |
| HDD seek | 10 ms |
| Same-datacenter round trip | 0.5 ms |
| Cross-region (US ↔ Europe) | 150 ms |
The rule of thumb: RAM is fast, disk is slow, network is in between, geography is expensive.
Storage Units
| Unit | Size |
|---|---|
| 1 character | 1 byte |
| Short tweet (280 chars) | ~280 bytes |
| Metadata row | ~1 KB |
| Mobile-quality photo | 1–3 MB |
| High-res photo | 3–8 MB |
| 1 min compressed video (720p) | ~50 MB |
| 1 hour 4K video | ~7 GB |
Time Shortcuts
| Period | Seconds |
|---|---|
| 1 minute | 60 s |
| 1 hour | 3,600 s |
| 1 day | ~86,400 s ≈ 100K s |
| 1 month | ~2.5M s |
| 1 year | ~30M s |
The most useful approximation: 1 day ≈ 100,000 seconds. This converts requests/day to QPS instantly.
2. The Estimation Framework
Every capacity estimate follows the same sequence.
Step 1 — Users How many registered users? How many are daily active (DAU)? Rule of thumb: DAU ≈ 10–20% of registered users for most consumer apps.
Step 2 — Requests How many requests does each DAU generate per day? Separate reads from writes — they have different infrastructure implications.
Step 3 — QPS Average QPS = Total requests per day / 86,400 Peak QPS ≈ Average QPS × 2–3 (traffic is not evenly distributed across the day)
Step 4 — Storage Data written per request × write QPS × retention period. Don't forget replication factor (typically 3×).
Step 5 — Bandwidth Average response size × read QPS. Distinguish inbound (writes) from outbound (reads) — they often differ by an order of magnitude.
3. Worked Example: A Twitter-Scale Feed Service
Given: Design a Twitter-like service.
- 300M registered users, 50M DAU
- Each user reads 20 tweets per session, 3 sessions/day → 60 reads/day
- Each user posts 0.1 tweets/day (most users only read)
- Average tweet: 300 bytes
QPS
- Read requests: 50M DAU × 60 reads/day = 3B reads/day → 3B / 100K = 30,000 read QPS
- Write requests: 50M × 0.1 = 5M tweets/day → 5M / 100K = 50 write QPS
- Peak read QPS (~3× spike): ~90,000 QPS
Storage
- 5M tweets/day × 300 bytes = 1.5 GB/day of tweet text
- × 3 replicas = 4.5 GB/day
- Per year: 4.5 GB × 365 ≈ ~1.6 TB/year (text only — media is separate)
Bandwidth
- Read traffic: 30,000 QPS × 300 bytes = 9 MB/s outbound
The insight: 600:1 read-to-write ratio means caching is critical. The write path is simple; the read path needs aggressive optimisation — pre-computed feeds, Redis caching, CDN for media.
4. Worked Example: A YouTube-Scale Video Platform
Given: Design a video storage and delivery service.
- 2B registered users, 400M DAU
- 500 hours of video uploaded every minute
- Average upload: 300 MB raw, compressed to 150 MB for delivery
- Each user watches 60 min/day at 720p (~500 MB/hour)
QPS
- 400M users × 1 video start/day = 400M video requests/day → 4,600 QPS of video start requests
- Video delivery is sustained streaming — each "view" is continuous throughput, not a single response
Storage
- Uploads: 500 hours/min × 60 min × 300 MB = 9,000 GB/min = ~9 TB/minute incoming
- YouTube stores multiple quality tiers (360p, 720p, 1080p, 4K) — roughly 3× multiplier
- Plus replication across regions: 3×
- Effective rate:
9 TB × 3 × 3 = **80 TB/minute** stored
Bandwidth
- 400M users × 60 min/day × (500 MB / 60 min) = 400M × 8.3 MB = 3.3 PB/day outbound
- 3.3 PB / 86,400 s ≈ 38 GB/s sustained outbound
The insight: No origin server handles 38 GB/s. At this scale, CDN edge caching at hundreds of points of presence is not optional — it is the architecture. Origin serves only cache misses.
5. Summary
| Step | What you're answering |
|---|---|
| Users → DAU | Who actually uses this daily? |
| DAU → Requests | How many reads and writes per user? |
| Requests → QPS | ÷ 86,400. Peak ≈ 3× average. |
| Writes → Storage | Size × writes/day × retention × replication factor |
| Reads → Bandwidth | Response size × read QPS |
The Architect's Takeaway
Estimation is not about the exact number — it is about knowing which regime you are in. Millions-QPS requires distributed caching, CDN, and sharding. Thousands-QPS might be handled by a well-tuned monolith. The architecture follows from the numbers, not the other way around. State your assumptions explicitly, do the math out loud, and let the numbers drive your design choices.