System Design Foundations
Back-of-Envelope Estimation
Before designing anything, size it: rough QPS, storage, and bandwidth numbers derived from user counts turn "make it fast" into concrete, checkable design constraints.
- Start from DAU (daily active users) × actions/user/day to get total daily requests, then divide by 86,400 seconds for average QPS
- Peak QPS is typically 2-3× average QPS — traffic is not uniform across the day
- Storage estimate = new records/day × average record size × retention period, then multiply by the replication factor
- Memorize the powers-of-two cheat sheet: 2¹⁰ ≈ 10³ (KB), 2²⁰ ≈ 10⁶ (MB), 2³⁰ ≈ 10⁹ (GB), 2⁴⁰ ≈ 10¹² (TB)
- The goal is order-of-magnitude, not precision — round aggressively (500M users → "call it 10⁹") and sanity-check the final number against known references
| Power | Exact value | Approx. |
|---|---|---|
| 2¹⁰ | 1,024 | 1 thousand (KB) |
| 2²⁰ | 1,048,576 | 1 million (MB) |
| 2³⁰ | ~1.07 billion | 1 billion (GB) |
| 2⁴⁰ | ~1.1 trillion | 1 trillion (TB) |
long dailyActiveUsers = 50_000_000L;
int postsPerUserPerDay = 2;
int avgPostSizeBytes = 500; // text + metadata
int retentionDays = 365 * 5; // 5-year retention
int replicationFactor = 3;
long dailyPosts = dailyActiveUsers * postsPerUserPerDay;
long dailyStorageBytes = dailyPosts * avgPostSizeBytes;
long totalStorageBytes = dailyStorageBytes * retentionDays * replicationFactor;
// ~50M * 2 * 500B * 1825 days * 3 replicas =~ 274 PB — time to talk about shardingA useful discipline: derive QPS, storage, and bandwidth separately, since each stresses a different part of the system. QPS stresses compute and connection handling (Load Balancing); storage stresses disk and partitioning; bandwidth stresses network links and can surface surprising bottlenecks (e.g. video upload traffic saturating an origin's NIC well before its CPU is stressed).