Theory
Back-of-the-Envelope Estimation
📋 Overview
Back-of-the-envelope estimation is a quick, rough calculation performed to validate the feasibility of a system design. In engineering, it helps identify potential bottlenecks (storage, bandwidth, QPS) and make informed architectural decisions (e.g., whether to use a single database or a sharded cluster) before investing time in implementation.
🏗️ Core Principles & Characteristics
- The Power of Two: Thinking in binary units for capacity planning (2^10 = 1KB, 2^20 = 1MB, 2^30 = 1GB, 2^40 = 1TB).
- Jeff Dean's Latency Numbers: Understanding relative speeds (L1 Cache: 0.5ns, RAM: 100ns, SSD: 16µs, Network: 150ms).
- QPS & Traffic: Calculating Queries Per Second based on Daily Active Users (DAU) (e.g., 100M DAU / 100k seconds ≈ 1,000 QPS).
- Availability (Nines): Calculating downtime (99.9% is ~9 hours/year; 99.99% is ~5 minutes/year).
- Data Dimensions: Estimating total storage by multiplying "Expected Objects" by "Average Object Size" and adding a 20-30% buffer for metadata/indexing.
⚖️ Trade-offs: Pros & Cons
- Pros:
- Feasibility Check: Instantly reveals if an approach is fundamentally broken (e.g., trying to store 1PB in a single MySQL instance).
- Focus: Helps prioritize the "heavy lifting" parts of the system.
- Speed: Requires only a napkin (or a whiteboard) and basic mental math.
- Cons:
- Lack of Precision: Real-world overheads (replication, logging, indexing) can make the actual requirements 2x-5x higher.
- Dependency on Assumptions: If your assumption about "average image size" is wrong, the entire calculation is off.
🌍 Real-World Implementation
- System Design Interviews: Demonstrating senior-level intuition by proving that a design can scale to millions of users.
- Capacity Planning: Deciding how many server racks or S3 buckets to provision for a new product launch.
- Cloud Cost Estimation: Predicting the monthly AWS bill for a proposed architecture.
💡 Interview "Gotchas" & Tips
- The "100k" Rule: There are 86,400 seconds in a day. Round to 100,000 for much faster mental division.
- Peak Load: Never design for average load. Always calculate for Peak QPS (usually 2x-5x higher than average).
- Read/Write Ratio: Always ask the interviewer for the ratio. A 100:1 ratio (read-heavy) suggests aggressive caching, while a 1:1 ratio (write-heavy) suggests sharding and message queues.
- Storage Buffer: Always account for replication (3x for HDFS/S3) and indexing overhead when estimating disk space.
📐 Suggested Architecture Primitives
- Standard Constants: Use Jeff Dean's latency table as your source of truth.
- Memory vs. Disk: Use 80/20 rule (cache 20% of data to serve 80% of traffic).
- Scalability: If QPS exceeds 10,000 or Storage exceeds 10TB, start discussing sharding and distributed databases.
Canvas