Back-of-the-Envelope Math
1. The mindset (say these to yourself first)
- The number doesn't matter, the chain does. Within 2–10× of reality is a pass. "Order of 10⁵ QPS" beats 92,341 QPS.
- Only compute what changes a decision. Every number must end with "…so therefore ___". A number with no consequence is wasted time.
- Round hard, say assumptions out loud. 100M users, not 123M. A stated wrong assumption is fine; a hidden one is a trap.
- Keep it under ~5 minutes. Interviewers dislike watching arithmetic.
The core fix for "too many variables": you never hold them all at once. You compute one number at a time, and each one is either memorised, assumed aloud, or derived from the previous one.
2. Chain A — Traffic (always first)
Assumptions to state at each arrow: DAU fraction 10–50%; actions per user per day = the core action(s); ÷ 100,000 because seconds in a day ≈ 10⁵; peak factor 2–10×, say which.
Then split into reads vs writes using a read:write ratio (assume one — feeds ~100:1, chat ~10:1). You design the two paths differently, so you need both.
Five steps, fixed order, one operation per arrow.
3. Chain B — Resources (derive from Chain A)
Only four things ever get sized. Every formula is count × size or load ÷ capacity.
| Resource | Formula | Decision it drives |
|---|---|---|
| Storage | writes/day × bytes/item × retention days | DB type, do I shard? |
| Bandwidth | QPS × bytes/item | CDN needed? |
| Memory / cache | items × bytes/item | Does the working set fit in RAM? |
| Machines | total load ÷ per-box capacity | Fleet size |
4. Anchors — memorise these
Time (the master shortcut)
Seconds in a day ≈ 100,000 (really 86,400).
| Per day | ≈ QPS |
|---|---|
| 1M | 10 |
| 100M | 1,000 |
| 1B | 10,000 |
| 100B | 1,000,000 |
Powers of two
| Power of 2 | Power of 10 | Approximates |
|---|---|---|
| 2¹⁰ | ~10³ | ~1 thousand → KB |
| 2²⁰ | ~10⁶ | ~1 million → MB |
| 2³⁰ | ~10⁹ | ~1 billion → GB |
| 2⁴⁰ | ~10¹² | ~1 trillion → TB |
Object sizes
| Thing | Size |
|---|---|
| 1 char | 1 byte |
| UUID / ID | ~16 B |
| Metadata row | 0.1–1 KB |
| Short text post | ~300 B (1 KB with metadata) |
| JSON API response | 1–10 KB |
| Photo | 200 KB thumb, ~1 MB full |
| Video | 10–50 MB per minute |
Latency (rounded to orders of magnitude)
| Operation | Time |
|---|---|
| L1 cache | 1 ns |
| Main memory | 100 ns |
| Read 1 MB from memory | 250 µs |
| Datacenter round trip | 500 µs |
| SSD random read | ~100 µs |
| Read 1 MB from SSD | ~1 ms |
| Disk seek | 10 ms |
| Read 1 MB from disk | ~20–30 ms |
| Cross-continent round trip | ~150 ms |
One takeaway: memory ~10× faster than SSD ~10× faster than disk, and a cross-region hop (~150 ms) dwarfs everything. That's what justifies caching, SSDs, and regional replicas.
Capacity — what one box does
| Box | Capacity |
|---|---|
| App server | 1K–10K QPS |
| WebSocket server (tuned) | ~500K idle connections |
| Redis node | ~100K ops/sec (up to 1M tuned) |
| Relational DB node | hundreds–few thousand writes/sec |
| SSD | tens of thousands IOPS |
Availability
| Nines | Downtime/year |
|---|---|
| 99% | ~3.65 days |
| 99.9% | ~8.8 hours |
| 99.99% | ~53 minutes |
| 99.999% | ~5 minutes |
5. Arithmetic so you never get stuck
1. Work in scientific notation. Separate digits from zeros. Multiply the small numbers, add the exponents. Divide → subtract exponents.
100M users × 10 actions = 10⁸ × 10¹ = 10⁹ /day
10⁹ ÷ 10⁵ sec = 10⁴ = 10,000 QPS2. Round every intermediate to one significant figure. 11.5 → 10. 7.3M → 10M. Error compounds far less than you fear.
3. Use the ÷100,000 reflex. Most QPS questions need no real division at all.
If you get stuck, say so and move on: "Order of 10⁵ QPS — the exact figure doesn't change the design, I'll proceed." Interviewers prefer this to watching you grind.
6. Four worked templates
QPS
200M DAU × 2 posts/day = 4×10⁸ /day
4×10⁸ ÷ 10⁵ = 4,000 writes/sec → peak ×5 = 20K/sec
200M × 100 reads/day = 2×10¹⁰ /day
2×10¹⁰ ÷ 10⁵ = 200K reads/sec → peak ×5 = 1M/sec→ read:write ≈ 50:1 → read-heavy → aggressive caching + fanout-on-write
Storage
4×10⁸ posts/day × 300 B = 1.2×10¹¹ B/day ≈ 120 GB/day
× 365 × 5 ≈ 200 TB over 5 years→ way past one node → sharded / wide-column, not a single RDBMS Media dominates: 10% carrying a 200 KB image = ~8 TB/day, ~60× the text → object storage + CDN
Bandwidth
1M reads/sec × 300 B = 3×10⁸ B/s = 300 MB/s ≈ 2.4 Gbps→ fine for text off a fleet; media must come from a CDN
Machines / connections
100M users × 10% concurrent = 10M connections
10M ÷ 5×10⁵ per box = 20 servers → ~30 with headroom
10M × 10 KB/conn = 100 GB RAM total = 5 GB/box → trivial→ connection-count-bound, not memory-bound
100K events/sec × 50 members fanout = 5×10⁶ pub/sub msgs/sec
÷ 10⁵–10⁶ per Redis node = 5–10 shards→ shard the backplane
⚠️ Connections scale with concurrent users, not with messages. This is the most common slip.
7. How to perform it
- Announce the plan — "let me size traffic first, then storage and machines"
- State each assumption as you make it — invites correction early
- Walk Chain A out loud in scientific notation, writing numbers down
- Compute only the resources that matter — chat app → connections; photo store → storage + CDN
- End every number with the decision it drives ← this is what scores
- Sanity-check yourself — "10K writes/sec on one Postgres node? No, that's past a single node, so I'll shard." Catching your own infeasibility is a strong signal.
8. Common traps
| Trap | Fix |
|---|---|
| Sizing connections from message volume | Connections = concurrent users |
| Forgetting peak | Always × 2–10 and say which |
| Forgetting read:write split | Reads and writes are different designs |
| Computing storage but ignoring media | Media is usually 10–100× the text |
| Numbers with no conclusion | Every number ends with "therefore ___" |
| Grinding on arithmetic | Round to 1 sig fig, or skip and state the order |
9. Drill plan (≈2 weeks, light)
- Flashcard the anchors until ÷100,000 and the powers-of-two ladder are reflexive
- 5 min/day of scientific notation reps — "3×10⁸ × 4×10² = ?" → 1.2×10¹¹
- Run Chain A on 10 known systems — Twitter, WhatsApp, YouTube, Uber, Dropbox, URL shortener, Instagram, Netflix, Google Drive, notifications
- For each number, name the one decision it drives — that's the habit that converts correct math into interview points
You were never bad at the math. You were missing the procedure and the anchors.