Picture this: You're in a System Design interview. The interviewer asks, "Design Twitter. How much storage and bandwidth will we need for 5 years?" Your mind goes blank. Your palms sweat.
But here is the secret: Interviewers don't care about exact precision. They care about your engineering judgment, your core assumptions, and whether you can reason about scale under pressure.
This process is called Back-of-the-Envelope Estimation—making quick, approximate calculations to understand a system's scale in under 3 minutes. Here is the ultimate cheat sheet to master it.
🔢 The Cheat Sheet Metrics
You can't do math if you don't know the baseline numbers. Memorize these:
1. Powers of 2 (Data Units)
- $2^{10}$ = 1 Thousand = 1 KB
- $2^{20}$ = 1 Million = 1 MB
- $2^{30}$ = 1 Billion = 1 GB
- $2^{40}$ = 1 Trillion = 1 TB
- $2^{50}$ = 1 Quadrillion = 1 PB
2. Latency Numbers to Remember
- RAM Read: ~100 ns
- SSD Read: ~100 µs
- Network Round Trip (Same DC): ~500 µs
- HDD (Disk) Read: ~10 ms
- Network Round Trip (Cross-Region): ~150 ms
3. The High Availability "Nines"
- 99% (Two Nines): ~3.6 days downtime/year
- 99.9% (Three Nines): ~8.7 hours downtime/year
- 99.99% (Four Nines): ~52 minutes downtime/year
🗺️ The 4-Step Estimation Framework
Never guess randomly. Follow this sequential pipeline to calculate scale methodically:
+---------------+ +-----------+ +---------------+ +------------------+
| Traffic (RPS) | ----> | Storage | ----> | Bandwidth | ----> | Servers Needed |
+---------------+ +-----------+ +---------------+ +------------------+
Step 1: Traffic Estimation 🚦
-
Formula:
RPS = (DAU × Requests per user per day) / 86,400 - Pro-Tip: Round 86,400 seconds in a day to 100,000 for fast interview math!
- Example (300M DAU, 1 write/day): $300\text{M} / 100,000 = \mathbf{3,000\text{ Write RPS}}$.
Step 2: Storage Estimation 💾
-
Formula:
Storage = Items per day × Average Item Size × Retention Period - Example: 3,000 writes/sec $\approx$ 300M items/day. At 1 KB per item, that's 300 GB/day. Over 5 years ($300\text{ GB} \times 365 \times 5$), you'll need roughly 547 TB.
Step 3: Bandwidth Estimation 🌐
-
Formula:
Bandwidth = RPS × Average Payload Size - Example: If your system has 300,000 Read RPS and a 1 KB payload, you need 300 MB/s throughput. This immediately tells you that you must use a CDN to avoid crashing your core database.
Step 4: Server Estimation 🖥️
-
Formula:
Servers = Total RPS / RPS a single server can handle - Assumption: A standard commodity web server can safely handle between 1,000 to 10,000 RPS depending on workload.
- Example: For 300,000 Read RPS at 10,000 RPS/server, you need 30 base servers. Multiply by a 3x safety factor for traffic spikes $\approx$ 90 servers.
🚀 Deep Dive: Real-World Interview Scenarios
How does this work for different system architectures? It depends entirely on what you are building.
I have written down the full, step-by-step mathematical breakdowns for the most common system design interview questions on my blog. Dive deep into the specific calculations here:
- 🔗 How to estimate storage for a URL Shortener like Bit.ly (Where payloads are tiny but read/write ratios are highly skewed).
- 🔗 How to calculate Petabyte-scale storage for Instagram Photos (Where media compression ratios drastically shift your daily storage requirements).
🎯 Key Takeaways
- Round aggressively. Nobody cares about the difference between 86,400 and 100,000 during an estimation drill.
- State your assumptions clearly. The interviewer wants to see how you think, not if you memorized the exact size of Twitter's database.
- Sanity check your numbers. If your final storage calculation says 500 PB for a simple text-based app, take a breath and check your decimals.
🛠️ Want to master the full framework?
For the absolute complete guide—including data sizing charts for data types (UUIDs, ASCII vs Unicode) and availability tables—read the original deep dive on TechPaths: Back-of-the-Envelope Estimation.
How do you handle napkin math during interviews? Let's discuss in the comments below! 👇
Top comments (0)