System Design - Estimations Cheat Sheet

In system design interviews, back-of-the-envelope calculations are not about computing exact numbers down to the third decimal place. Interviewers use estimations to evaluate whether you have a solid grasp of engineering scale, can identify the primary resource bottlenecks (RAM vs. Disk vs. Network bandwidth), and know how to choose the right database and hardware profile.

The Mental Math Conversion Table

Memorize these mental conversion shortcuts to perform rapid conversions without a calculator:

Time & Frequency Conversions

• 1 day = 24 hours × 3,600 seconds = 86,400 seconds ≈ 100,000 ($10^5$) seconds
• 1 hour = 3,600 seconds ≈ $4,000$ seconds
• 1 million requests / day ≈ $\frac{1,000,000}{86,400} \approx$ 12 requests / second (QPS)
• 10 million requests / day ≈ 120 QPS
• 100 million requests / day ≈ 1,200 QPS
• 1 billion requests / day ≈ 12,000 QPS

Always remember to factor in Peak Traffic:

• Peak QPS = Average QPS × Peak Factor (typically $2\times$ to $5\times$).
• For example, if an application averages 1,200 QPS, design the stateless web tier and database connection pools for 2,400 to 6,000 peak QPS.

Data Storage & Powers of Two

Latency Numbers Every Engineer Should Know

Understanding order-of-magnitude latencies (originally compiled by Jeff Dean) determines where to place caches, whether to batch network calls, and when disk operations will kill your service:

Architectural Takeaways from Latency

1. Memory is 1,000x faster than NVMe SSD, and 100,000x faster than spinning disk seeks.
2. Sequential reads are 10x to 100x faster than random seeks on both SSDs and HDDs.
3. Network round-trips dominate total latency. Minimizing cross-datacenter queries and leveraging connection pooling and HTTP/2 or HTTP/3 multiplexing is paramount.

Standard Estimation Template (Step-by-Step)

Whenever prompted to estimate scale in an interview, run through this 4-step sequence:

1. Throughput (QPS)

• Given: 300 million Daily Active Users (DAU). Each user views 10 posts and creates 1 post per day.
• Read QPS: $\frac{300,000,000 \times 10}{100,000} = 30,000$ read QPS.
• Write QPS: $\frac{300,000,000 \times 1}{100,000} = 3,000$ write QPS.
• Read / Write Ratio: $10:1$.
• Peak Write QPS: $3,000 \times 2 = 6,000$ QPS.

2. Storage & Retention (Disk Capacity)

• Post Payload Size: 500 bytes (text + metadata) + 20% index overhead ≈ 600 bytes.
• Daily Ingress: $300,000,000 \text{ posts} \times 600 \text{ bytes} \approx 180 \text{ GB / day}$.
• Annual Storage (1 Year): $180 \text{ GB} \times 365 \approx 65 \text{ TB / year}$.
• 5-Year Capacity: $65 \text{ TB} \times 5 \approx 325 \text{ TB}$.
• Replication Overhead (Factor of 3 for High Availability): $325 \text{ TB} \times 3 \approx 1 \text{ PB}$ total raw storage required over 5 years.

3. Cache Working Set (RAM Capacity)

Apply the Pareto 80/20 Rule: 20% of content drives 80% of all read traffic.

• Target: Cache 20% of the daily read working set in Redis: $$\text{Cache RAM} = 300,000,000 \text{ daily posts} \times 600 \text{ bytes} \times 0.20 \approx 36 \text{ GB RAM}$$
• A standard cloud memory instance (e.g., AWS r6g.xlarge with 32GB RAM or two 32GB nodes in a cluster) comfortably holds the entire active working set with headroom for overhead and metadata.

4. Network Bandwidth (Egress & Ingress)

• Write Ingress: $3,000 \text{ writes/sec} \times 600 \text{ bytes} \approx 1.8 \text{ MB/sec} = 14.4 \text{ Mbps}$.
• Read Egress: $30,000 \text{ reads/sec} \times 600 \text{ bytes} \approx 18 \text{ MB/sec} = 144 \text{ Mbps}$.
• Conclusion: Bandwidth is not a primary bottleneck; standard 1Gbps or 10Gbps network interfaces handle this workload without special hardware.

High Availability & Service Level Agreement (SLA) "Nines"

Calculate acceptable downtime per year when evaluating non-functional requirements: