Back-of-Envelope Estimation

Back-of-envelope estimation is the practice of making rough calculations using approximate values and simplified assumptions to quickly assess the feasibility of a system design — determining storage needs, throughput requirements, and infrastructure costs without precise data.

What It Really Means

In system design interviews and real engineering, you constantly need to answer questions like: "How many servers do we need?" "How much storage will this require in a year?" "Can a single database handle this load?" You rarely have precise data. What you have is the ability to make reasonable approximations.

Back-of-envelope estimation is not about getting the exact right answer. It is about getting the right order of magnitude — knowing whether you need 1 server or 100, 10GB or 10TB, 100 QPS or 100,000 QPS. Being off by 2x is fine. Being off by 100x means you designed the wrong system.

Jeff Dean's "Numbers Every Programmer Should Know" is the foundation. Knowing that a disk seek takes 10ms, a round trip within a datacenter takes 0.5ms, and reading 1MB from memory takes 0.25ms lets you reason about system performance without benchmarking.

How It Works in Practice

Key Numbers to Memorize

Powers of 2 and 10

Example: Estimate Storage for a URL Shortener

Example: Estimate QPS for Twitter

Example: How Many Servers?

Implementation

Estimation template for interviews:

Trade-offs

When estimation matters:

• Choosing between single-server and distributed architecture
• Deciding whether to shard a database or add read replicas
• Estimating infrastructure costs for budgeting
• Identifying bottlenecks before they occur

Common estimation pitfalls:

• Using averages instead of peaks (design for 10x average)
• Forgetting replication overhead (3x for triple replication)
• Ignoring metadata and indexes (often 2-3x raw data size)
• Assuming linear scaling (diminishing returns above 70% utilization)

Precision vs speed:

• Interview: Round aggressively. 86,400 seconds/day -> 100,000. Close enough.
• Production capacity planning: Use actual measurements and load testing
• Architecture decision: Order-of-magnitude estimates determine the right architecture

Common Misconceptions

• "You need exact numbers" — The goal is order of magnitude. Is it 10GB or 10TB? 100 QPS or 100,000 QPS? The architecture differs dramatically between these, but 15TB vs 10TB uses the same architecture.
• "Memory is expensive" — In 2026, 256GB of RAM costs about $500/month on cloud providers. Keeping 100GB of data in memory is often cheaper than optimizing complex caching logic.
• "You should always shard" — A single PostgreSQL instance handles 10,000+ writes/second and stores terabytes. Many systems never need sharding.
• "More servers = better" — Each server adds operational complexity, failure modes, and coordination overhead. Fewer, larger servers are often better than many small ones.
• "Bandwidth is unlimited" — A 10Gbps network link transfers 1.25GB/second. If your API response is 100KB and you serve 100,000 QPS, that is 10GB/second — you need multiple network links.

How This Appears in Interviews

1. "Estimate the storage needed for YouTube" — 500 hours of video uploaded per minute. Average video: 1080p at 150MB/min. Daily: 500 * 60 * 24 * 150MB = 6.5PB/day of raw video. With multiple resolutions: 3-5x = 20-30PB/day.
2. "How many servers for a chat application with 10M concurrent users?" — Estimate messages per second, connections per server, memory per connection.
3. "Will this database handle our load?" — Calculate QPS, compare to database benchmarks. PostgreSQL: ~10K writes/s, ~50K reads/s. Redis: ~100K ops/s.
4. "Estimate the cost of running this system" — Servers, storage, bandwidth, managed services. Use cloud pricing as a reference.*

Related Concepts

• Tail Latency — latency numbers are the foundation of estimation
• Database Partitioning — estimation tells you when you need to shard
• Read Replicas — estimation determines how many replicas you need
• SLOs, SLIs, and SLAs — estimation validates whether SLOs are achievable
• Snowflake ID vs UUID — estimate ID space exhaustion
• System Design Interview Guide
• Algoroq Pricing — access all concept deep-dives