Back of the Envelope Estimation: System Design Math Every Engineer Should Know

Back of the envelope estimation is the skill of quickly approximating system requirements using rough math. In system design interviews and real-world architecture planning, you need to answer questions like: How many servers do we need? How much storage will we use in a year? What QPS should we design for? This guide covers the numbers, formulas, and mental models that make these calculations second nature.

Why Estimation Matters#

Precise answers are not the goal. The goal is to arrive at the correct order of magnitude — knowing whether you need 10 servers or 10,000 changes every downstream decision. Estimation exposes bottlenecks early, validates architecture choices, and demonstrates structured thinking in interviews.

Numbers Every Engineer Should Know#

These latency and size benchmarks form the foundation of all estimation work. Memorize the order of magnitude, not the exact number.

Latency Numbers#

Key insight: Memory is 250x faster than SSD. SSD is 250x faster than HDD. Network within a datacenter is under 1ms. These ratios drive caching and storage decisions.

Storage and Throughput Numbers#

Power-of-Two Shortcuts#

Time Conversions#

Use 10^5 seconds per day as the go-to shortcut. It simplifies QPS calculations enormously.

QPS Estimation#

Queries per second is the most common estimation target. The formula:

QPS = Daily Active Users x Actions per User per Day / Seconds per Day

QPS = DAU x actions / 10^5

Example: Twitter-like service

• 300 million DAU
• Each user views 20 tweets per day on average
• Read QPS = 300M x 20 / 100,000 = 60,000 QPS
• Peak QPS = 2-3x average = 120,000 - 180,000 QPS

Example: URL shortener

• 100 million DAU
• Each user creates 0.1 short URLs per day (mostly reads)
• Write QPS = 100M x 0.1 / 100,000 = 100 QPS
• Read QPS (100:1 ratio) = 10,000 QPS

Always estimate peak as 2-5x the average. Systems must handle peaks, not averages.

Storage Estimation#

Storage estimation follows a simple pattern:

Storage = Number of Records x Average Record Size x Retention Period

Example: Chat application

• 50 million messages per day
• Average message size: 200 bytes (text + metadata)
• Retain for 5 years

Daily storage  = 50M x 200 bytes = 10 GB/day
Yearly storage = 10 GB x 365 = 3.65 TB/year
5-year storage = 3.65 TB x 5 = ~18 TB

With replication factor 3, total storage = ~54 TB. This is well within a modest cluster.

Example: Image hosting

• 10 million uploads per day
• Average image size: 500 KB
• Retain indefinitely

Daily storage  = 10M x 500 KB = 5 TB/day
Yearly storage = 5 TB x 365 = 1.8 PB/year

This is a fundamentally different scale — you need object storage (S3) and a CDN, not a database.

Bandwidth Estimation#

Bandwidth tells you how much network capacity you need.

Bandwidth = QPS x Average Response Size

Example: Video streaming

• 100,000 concurrent streams
• Average bitrate: 5 Mbps

Bandwidth = 100,000 x 5 Mbps = 500 Gbps

This requires multiple PoPs (points of presence) and CDN distribution. No single datacenter serves this.

Memory Estimation#

The classic caching rule: cache the hot 20% of data (Pareto principle — 20% of data serves 80% of requests).

Memory = Daily Read Volume x Average Object Size x 0.2

Example: Key-value cache for a social feed

• 10 million unique posts accessed per day
• Average post object: 1 KB

Memory = 10M x 1 KB x 0.2 = 2 GB

A single Redis instance handles this easily. At 100 million posts with 10 KB objects, you need 200 GB — a Redis cluster across several nodes.

Server Count Estimation#

Each server can handle a finite number of requests depending on the workload type.

Rules of thumb:

• CPU-bound web server: 1,000 - 10,000 QPS (depends on response complexity)
• I/O-bound API server: 5,000 - 50,000 QPS (with async I/O)
• Database server: 5,000 - 20,000 QPS (indexed reads)

Servers = Peak QPS / QPS per Server

Example: API service at 100,000 peak QPS

• Each server handles ~10,000 QPS
• Servers needed: 100,000 / 10,000 = 10 servers
• With 2x headroom for failover: 20 servers

Practice Problems#

Problem 1: Design storage for a ride-sharing service#

Given: 10 million rides per day. Each ride record is 500 bytes. Retain 3 years.

Daily   = 10M x 500 B = 5 GB/day
Yearly  = 5 GB x 365 = 1.8 TB/year
3 years = 5.4 TB
With 3x replication = ~16 TB total

This fits comfortably in a single sharded database cluster.

Problem 2: QPS for a notification system#

Given: 200 million DAU. Each user receives 5 notifications per day. 80% are delivered via push, 20% via pull (user opens app).

Push QPS = 200M x 5 x 0.8 / 100,000 = 8,000 QPS
Pull QPS = 200M x 5 x 0.2 / 100,000 = 2,000 QPS
Total outbound QPS ~ 10,000
Peak ~ 30,000 QPS

Problem 3: CDN bandwidth for an e-commerce site#

Given: 50,000 concurrent users. Average page load: 2 MB (images, JS, CSS). Average session: 10 pages in 10 minutes.

Pages per second = 50,000 x 10 / 600 = ~833 pages/sec
Bandwidth = 833 x 2 MB = 1.67 GB/s = ~13 Gbps

This is a moderate CDN load — a few edge PoPs handle it easily.

The Estimation Framework#

When faced with any estimation question, follow this sequence:

1. Clarify scope — What metric are we estimating? Over what time period?
2. State assumptions — DAU, actions per user, object sizes, retention. Write them down.
3. Do the math — Use round numbers and powers of 10. Show your work.
4. Sanity check — Does the result make sense? Compare to known systems.
5. Identify bottlenecks — Which resource (storage, bandwidth, QPS, memory) is the limiting factor?

Common Pitfalls#

• Forgetting peak vs. average — Always multiply average QPS by 2-5x for peak.
• Ignoring replication — Storage estimates must account for replication factor (typically 3x).
• Mixing units — Keep everything in consistent units. Convert early.
• Over-precision — Rounding 86,400 to 10^5 is not just acceptable, it is expected. The goal is order of magnitude.
• Forgetting metadata overhead — Indexes, headers, and encoding can add 20-50% to raw data size.

Key Takeaways#

1. Memorize latency numbers (L1 to cross-continent) and storage powers of two.
2. Use 10^5 seconds per day as your universal QPS denominator.
3. Always estimate peak (2-5x average) and account for replication (3x storage).
4. Cache the hot 20% of data — this drives memory estimation.
5. Show your work: state assumptions, do math, sanity check.
6. The goal is the correct order of magnitude, not decimal precision.

---

If you found this guide helpful, explore our full library of 253 system design and engineering articles at codelit.io.