System Design
Back-of-the-Envelope Capacity Math
The powers of two, time constants, and object sizes that turn “design for 100M users” into concrete QPS, storage, and bandwidth in your head — deliberately order-of-magnitude, not false precision.
Updated August 30, 2026 · 5 min read
Powers of two → readable sizes
| 2¹⁰ | ≈ 1 thousand (1,024)KB |
|---|
| 2²⁰ | ≈ 1 millionMB |
|---|
| 2³⁰ | ≈ 1 billionGB |
|---|
| 2⁴⁰ | ≈ 1 trillionTB |
|---|
| 2⁵⁰ | ≈ 1 quadrillionPB |
|---|
Time constants
| Seconds per day | 86,400 ≈ 10⁵the single most useful number |
|---|
| Seconds per month | ≈ 2.5 million |
|---|
| Seconds per year | ≈ 31.5 million ≈ 3×10⁷ |
|---|
Typical object sizes
| int / timestamp | 4 / 8 bytes |
|---|
| UUID | 16 bytes |
|---|
| A tweet-sized text row | ~1 KB |
|---|
| A metadata row (DB) | ~1 KB |
|---|
| Compressed photo | ~100 KB – 1 MB |
|---|
| 1080p video, per minute | ~30–50 MB |
|---|
The formulas
| Average QPS | DAU × req/user/day ÷ 86,400 |
|---|
| Peak QPS | avg × 2–10pick a peak factor and say it |
|---|
| Write vs read split | avg ÷ (R+1) writes; ×R/(R+1) readsR = reads per write |
|---|
| New storage / year | writes/day × object size × 365 |
|---|
| Hot cache size | ~20% of daily read bytesthe 80/20 rule |
|---|
| Peak egress | peak read QPS × object size × 8 bits |
|---|
In the interview
- →State every assumption out loud (DAU, requests/user, peak factor). A stated assumption you can defend beats a “right” number you can’t.
- →Round aggressively to powers of ten. The interviewer wants to see you reach the right order of magnitude with confidence, not do long division.
- →The numbers are the argument: they’re what justify “we need to shard” or “a single Postgres is fine.” Compute first, then decide.