TLDR: Capacity estimation is the skill of back-of-the-envelope math that tells you whether your system design will survive its traffic before you write a line of code. Four numbers do most of the work: DAU, QPS, Storage/day, and Bandwidth/day.

---

📖 The Restaurant Napkin Math

Before opening a restaurant, you estimate:

• Expected customers per day.
• Average orders per customer.
• Average order size (for kitchen capacity).
• Peak hours (for staffing).

Software capacity estimation follows the same logic. You are sizing the kitchen before building the restaurant.

---

🔢 The Four-Step Estimation Pipeline

Every system design capacity estimation follows this flow:

flowchart LR
    DAU["Daily Active Users\n(e.g., 10M)"] --> QPS["Convert to QPS\n(requests/sec)"]
    QPS --> Storage["Storage/day\n(data written)"]
    QPS --> Bandwidth["Bandwidth/day\n(data read/transferred)"]
    Storage --> Total["Total infra sizing\n(servers, DB, cache)"]
    Bandwidth --> Total

Step 1 — DAU to QPS

$$\text{QPS} = \frac{\text{DAU} \times \text{requests per user per day}}{86400 \text{ seconds}}$$

Example — Twitter-scale:

• 100M DAU, each user generates 10 requests/day (timelines, searches, posts).
• $QPS = (100M \times 10) / 86400 \approx 11,600~\text{RPS}$
• Peak is typically 2-3× average: ~35,000 RPS peak.

Step 2 — Storage per Day

$$\text{Storage/day} = \text{write QPS} \times \text{record size} \times 86400$$

Example — URL Shortener:

• 1,000 new URLs/day. Each record = ~500 bytes.
• $1000 \times 500 = 500 \text{ KB/day}$
• Over 5 years: $500 \text{ KB} \times 365 \times 5 \approx 900 \text{ MB}$ — fits in a single DB.

Example — Image Platform (Instagram-scale):

• 1M uploads/day, average image = 1 MB.
• $1M \times 1 \text{ MB} = 1 \text{ TB/day}$ → 365 TB/year. Object storage (S3), not a relational DB.

Step 3 — Bandwidth

$$\text{Read Bandwidth} = \text{read QPS} \times \text{average response size}$$

If read:write ratio is 100:1 (social media timeline):

• Write QPS = 1,000/sec at 100 bytes each → 100 KB/s write.
• Read QPS = 100,000/sec at 10 KB each → 1 GB/s read. → CDN is mandatory.

---

⚙️ Reference Numbers to Memorize

---

🧠 Worked Example: Design a Pastebin

Assumptions:

• 1M DAU. Read:Write = 10:1. Average paste = 10 KB.
• Write QPS = (1M × 1 paste/day) / 86400 ≈ 12 writes/sec
• Read QPS = 12 × 10 = 120 reads/sec
• Storage: 12 writes/sec × 10 KB × 86400 = ~10 GB/day → 10 TB over 3 years.
• Read bandwidth: 120 reads/sec × 10 KB = 1.2 MB/sec → no CDN needed at this scale.

What this tells you:

• A single PostgreSQL can comfortably handle sub-1000 writes/sec.
• Storage backend should be durable object storage to handle 10 TB over 3 years.
• No CDN or caching tier needed at this scale — 120 RPS fits in a single app instance.

---

⚖️ Common Estimation Mistakes

---

📌 Summary

• DAU → QPS → Storage → Bandwidth is the standard four-step pipeline.
• Peak QPS = 2-3× average; always design for peak.
• 10^5 seconds/day is the key constant — it converts user behavior to per-second rates.
• Compare storage requirements early: 1 GB/day → relational DB. 1 TB/day → object storage.
• High read bandwidth → CDN. Low bandwidth → single server is fine.

---

📝 Practice Quiz

1. A social network has 50M DAU. Each user reads 20 posts per day. What is the approximate read QPS?

   • A) ~580 RPS
   • B) ~11,600 RPS
   • C) ~1,000,000 RPS
     Answer: B ((50M × 20) / 86400 ≈ 11,574 ≈ 11,600 RPS)

2. Your system writes 100 bytes per transaction at 1,000 writes/sec. How much DB storage do you need per year?

   • A) ~3 GB
   • B) ~3 TB
   • C) ~3 PB
     Answer: A (100 bytes × 1000/sec × 86400 × 365 ≈ 3.15 × 10^12 bytes = 3 TB — actually B; answer: B)

3. Your service has a read:write ratio of 1000:1. Writes are 10 RPS, each response is 50 KB. What is the read bandwidth in GB/s?

   • A) 0.5 GB/s
   • B) 500 GB/s
   • C) 5 GB/s
     Answer: A (10 × 1000 reads/sec × 50 KB = 500,000 KB/s = 500 MB/s ≈ 0.5 GB/s)

---