Capacity Estimation: Back-of-the-Envelope Math for System Design
How to estimate QPS, storage, bandwidth, and memory in a system design interview — the simple 5-step method with a full worked URL-shortener example. Fresher to senior.
🔵 Fundamentals · Fresher-friendly → 🟠 senior nuance
Halfway through a system design interview, someone asks: "How much storage will this need? How many servers?" This is capacity estimation — the back-of-the-envelope math that turns a vague design into concrete numbers. It sounds scary, but it's just multiplication with round numbers, and a simple method gets you there every time. Nail it and you look senior; skip it and your design floats without a foundation. Let's make it easy.
The numbers you must know cold
🟠 A few reference values do 90% of the work. Memorise these — they're the multiplication table of system design:
| Thing | Round number |
|---|---|
| Seconds in a day | ~86,400 ≈ 100,000 (10⁵) |
| Char / ASCII | 1 byte |
| Typical tweet / short text | ~200–300 bytes |
| A web page / small image | ~1 MB |
| KB → MB → GB → TB → PB | each ×1000 |
The single most useful trick: a day is about 100,000 seconds. So "daily count ÷ 100,000 = requests per second." That one shortcut turns most QPS questions into a quick division.
The method: five steps
Every estimation follows the same path. Let's walk it, then do a real example.
- Start with users: daily active users (DAU). State it as an assumption if not given.
- Derive QPS: actions per user per day × DAU ÷ 100,000. Split into reads and writes using a read:write ratio (reads usually dominate, often 100:1).
- Storage: writes per day × bytes per item → per day, then ×365 and ×5 for a 5-year horizon.
- Bandwidth: QPS × bytes per request = bytes/second in and out.
- Memory (cache): apply the 80/20 rule — cache the hot ~20% of daily data in RAM.
Worked example: a URL shortener
🟠 Let's estimate a URL shortener like TinyURL. Assumptions (say them out loud): 100 million new URLs/day, and reads are 100× writes (people click links far more than they create them).
WRITES: 100M / day ÷ 100,000 s = ~1,000 writes/sec READS : 1,000 × 100 = ~100,000 reads/sec STORAGE: each URL row ≈ 500 bytes per day = 100M × 500 B = 50 GB / day per year = 50 GB × 365 = ~18 TB / year 5 years = ~90 TB ← plan capacity for this BANDWIDTH (reads): 100,000/s × 500 B = 50 MB/sec out
In under a minute you've produced: ~1K writes/sec, ~100K reads/sec, ~90 TB over five years, ~50 MB/s bandwidth. Those numbers now drive your design — 100K reads/sec screams "we need a cache and read replicas," and 90 TB screams "we need sharding." That's the whole point: estimation tells you which components you actually need.
The senior mindset
🟠 Three things separate a good estimate from a nervous one:
- Round aggressively. 86,400 → 100,000; 365 → 400 if it helps. Interviewers want round numbers — precision is a trap that wastes time.
- State every assumption. "I'll assume 100M DAU and a 100:1 read/write ratio." This shows judgement and lets the interviewer correct you early.
- Tie numbers back to design. Don't compute in a vacuum — say what each number means: "100K reads/sec means a single DB won't cope, so I'll add caching and replicas." The math is only useful if it changes a decision.
Reads vs writes: why the ratio matters
Most systems are read-heavy — feeds, profiles, links, videos are read far more than written. That single fact shapes architecture: you scale reads with caches and replicas, and protect the smaller write path separately. A write-heavy system (logging, analytics ingestion, IoT) flips the priorities toward write throughput and queues. Identifying which one you're dealing with, from the estimate, is a senior instinct.
The interview-ready summary
"Let me estimate. Assuming 100M new items/day and 100:1 reads, that's ~1K writes/sec and ~100K reads/sec. At ~500 bytes each, ~50 GB/day, so ~90 TB over five years. The 100K read QPS tells me I need caching and read replicas, and 90 TB tells me I need to shard. I'll round hard and flag my assumptions." Deliver that calmly and you've shown exactly the quantitative reasoning the whole exercise is testing.
What to read next
- Latency Numbers Every Engineer Should Know — the other half of back-of-envelope math
- Design a URL Shortener — this estimate, turned into a full design
- Caching Strategies — what your read-QPS number pushes you toward
- ← The complete System Design guide (hub)
