What is back-of-the-envelope estimation in system design?

It is a quick order-of-magnitude calculation — done to one significant figure, in your head or on a napkin — that turns a workload (daily active users, actions per user, payload size, retention) into the numbers that pick an architecture: queries per second, storage, bandwidth, and cache size. The goal is not precision but the right power of ten: knowing whether the answer is gigabytes or petabytes changes the design, and being off by 3× rarely does.

What are the latency numbers every programmer should know?

The canonical ladder, credited to Jeff Dean (originally Peter Norvig): an L1 cache reference is ~0.5 ns, a main-memory (RAM) reference ~100 ns, a 4 KB random read from SSD ~150 µs, a round trip within one datacenter ~500 µs, a disk seek ~10 ms, and a packet round trip across the world (California to the Netherlands) ~150 ms. The whole point is the ratios: memory is roughly 200× faster than an L1-to-RAM step suggests when you compare it to a disk seek — one disk seek is worth about 20 million L1 references.

How do you estimate QPS from daily active users?

Write QPS ≈ (daily active users × actions per user per day) ÷ 86,400 seconds. Round 86,400 to 100,000 (10^5) to keep it mental. Then peak QPS ≈ 2–3× the average to cover the daily traffic hump, and read QPS = write QPS × the read:write ratio (often 10:1 to 1000:1). Example: 100M users × 10 writes/day ÷ 10^5 s ≈ 10,000 writes/s average, ~20,000/s at peak.

How do you estimate storage for a system?

Storage per day = writes per day × average payload size; total storage = storage per day × the retention window. Multiply by a replication factor (often ×3) for the provisioned figure. Example: 100M photos/day × 2 MB = 200 TB/day; kept for 5 years that is roughly 200 TB × 1,825 days ≈ 365 PB before replication — which immediately tells you this lives on object storage, not in a database.

What is the 80/20 rule for cache sizing?

Assume 20% of the data serves 80% of the reads, so you only cache the hot 20%. Cache size ≈ 20% × (daily read requests × object size). It turns an impossible "cache everything" into a bounded working set — and when the number is still enormous, that is the estimate telling you the cache is a distributed tier of many machines, not a single box.

Back-of-the-Envelope: the Numbers That Design Systems

Before you draw a box, you do the arithmetic. Powers of two, the latency ladder, and a live calculator that turns daily users and payload size into QPS, storage, bandwidth, and cache — every formula shown.

Concept · Systems. The source ↗

A free, interactive, animated visual explainer of Back-of-the-Envelope: the Numbers That Design Systems — built to be understood, not skimmed.

Questions

What is back-of-the-envelope estimation in system design?: It is a quick order-of-magnitude calculation — done to one significant figure, in your head or on a napkin — that turns a workload (daily active users, actions per user, payload size, retention) into the numbers that pick an architecture: queries per second, storage, bandwidth, and cache size. The goal is not precision but the right power of ten: knowing whether the answer is gigabytes or petabytes changes the design, and being off by 3× rarely does.
What are the latency numbers every programmer should know?: The canonical ladder, credited to Jeff Dean (originally Peter Norvig): an L1 cache reference is ~0.5 ns, a main-memory (RAM) reference ~100 ns, a 4 KB random read from SSD ~150 µs, a round trip within one datacenter ~500 µs, a disk seek ~10 ms, and a packet round trip across the world (California to the Netherlands) ~150 ms. The whole point is the ratios: memory is roughly 200× faster than an L1-to-RAM step suggests when you compare it to a disk seek — one disk seek is worth about 20 million L1 references.
How do you estimate QPS from daily active users?: Write QPS ≈ (daily active users × actions per user per day) ÷ 86,400 seconds. Round 86,400 to 100,000 (10^5) to keep it mental. Then peak QPS ≈ 2–3× the average to cover the daily traffic hump, and read QPS = write QPS × the read:write ratio (often 10:1 to 1000:1). Example: 100M users × 10 writes/day ÷ 10^5 s ≈ 10,000 writes/s average, ~20,000/s at peak.
How do you estimate storage for a system?: Storage per day = writes per day × average payload size; total storage = storage per day × the retention window. Multiply by a replication factor (often ×3) for the provisioned figure. Example: 100M photos/day × 2 MB = 200 TB/day; kept for 5 years that is roughly 200 TB × 1,825 days ≈ 365 PB before replication — which immediately tells you this lives on object storage, not in a database.
What is the 80/20 rule for cache sizing?: Assume 20% of the data serves 80% of the reads, so you only cache the hot 20%. Cache size ≈ 20% × (daily read requests × object size). It turns an impossible "cache everything" into a bounded working set — and when the number is still enormous, that is the estimate telling you the cache is a distributed tier of many machines, not a single box.

Back-of-the-Envelope: the Numbers That Design Systems

Questions

Related explainers