Napkin math, fully shown.

Powers of two — the table you carry

Memorise five numbers. 2¹⁰ = 1 K, 2²⁰ = 1 M, 2³⁰ = 1 B, 2³² = 4 B, 2⁴⁰ = 1 T. Everything else follows. The pattern: every 10 extra bits is roughly three orders of magnitude, because 1024 ≈ 1000.

Practical use: a 64-bit signed ID holds 2⁶³ values — 9 quintillion, effectively infinite for any system you'll ever ship. A 32-bit user ID holds 2³¹, about 2 billion — which is the ceiling Facebook hit. When you're picking between int and bigint for a primary key, this table tells you whether you'll regret it in five years.

Latency numbers, with proportional bars

Jeff Dean's "numbers every programmer should know," redrawn so you can see the orders-of-magnitude gaps. The bars are on a log scale — each tick is 10×. Memorise the gaps, not the exact numbers.

The five derivations

1. 01 · DAU → average QPS
   avgQPS = DAU × actions_per_user_per_day / 86,400

   Each daily-active user does some number of actions: page views, messages sent, likes. Multiply, then divide by seconds-in-a-day (86,400, close enough to 100 K to round when you need to). 10M DAU × 5 actions = 50M actions/day ≈ 580 QPS average.

2. 02 · Average → peak QPS
   peakQPS = avgQPS × peak_multiplier (typically 3-5x)

   Traffic is never uniform. Peak hour of peak day usually lands 3–5× the daily average — more if your product has a strong daily rhythm (commute apps spike at 8am and 6pm). Size compute for peak with headroom. Size storage for average.

3. 03 · QPS → storage growth
   daily_storage = writes_per_day × avg_record_size × replication_factor × index_overhead

   Average record size has to include the value, index entries, replication overhead (typically 3×), and the metadata dark matter you never quite remember to count. A common mistake: thinking storage is "rows × size" when the real answer is closer to "rows × size × 3 × 1.3" for a replicated system with one secondary index.

4. 04 · QPS → instance count
   instances = ceil(peakQPS / sustainable_QPS_per_instance)

   Per-instance throughput depends on the workload (CPU-bound or IO-bound), but as a starting point: 100–500 QPS for a typical web service, 1000–2000 for a tight Go service, 10–50 for anything doing real work per request. Round up and add a 30% headroom buffer.

5. 05 · Storage → shard count
   shards = ceil(total_storage / storage_per_shard)

   A single shard caps around 500 GB to 1 TB before rebalancing turns painful. 50 TB of data needs 50–100 shards. Pick the next power of two above the calculation (32, 64, 128…) because resharding by doubling is much cleaner than by some arbitrary factor.

Try it — the live worksheet

Pick a DAU. The six derivations update live. Every assumption is a slider, so you can defend the input and let the math fall out.

Three worked examples

Three real product shapes, with the numbers run end to end. Same formulas. Wildly different system shapes once the input assumptions land.

What candidates get wrong

1. Skipping the assumptions. "5K QPS" with no stated DAU and actions-per-user can't be checked. Lead with the inputs so the interviewer can argue with a number instead of with your conclusion. The conclusion is the easy part; the inputs are the conversation.
2. Forgetting replication and indexes. A 10M-row table at 1 KB per row is 10 GB on disk only if there's one copy and zero indexes. With 3× replication and two indexes (each ~30% of base table size) the real number is closer to 50 GB. Multiply by 5, not by 1.
3. Sizing for average instead of peak. You don't size instance count for the daily average. Size it for the busiest minute of the busiest day, plus 30% slack. That 30% absorbs the variance Little's Law warns you about.
4. Using "10 ms" as if it means anything. 10 ms could be a local SSD read, a same-DC RPC, or three of them in sequence. The latency-numbers table above is the reference scale — use it.
5. Skipping bandwidth. Bandwidth quietly kills high-traffic services. A 100 KB response at 50K QPS is 40 Gbps — past the limit of a single NIC, which forces architectural choices (CDN, edge caching, shrinking the response). Run the multiplication.
6. Designing for ten years from now. 10× current peak is a sensible ceiling. Past that, you'll redesign before you ever get there. Twitter's 2010 architecture wouldn't survive 2026; 2026's architecture would have been over-engineered in 2010. Pick a horizon and live in it.

Little's Law, the escape hatch

When the math gets tangled, Little's Law bails you out. concurrency = throughput × latency. Name any two and the third writes itself. Most of the derivations on this page are Little's Law in disguise.

In practice: "100K QPS, each request takes 50 ms, so I need at least 5,000 concurrent slots." Whether those slots are threads, goroutines, async tasks, database connections, or HTTP/2 streams is the next conversation. The number itself is fixed by the equation.

Related on Semicolony

• Latency vs throughput — Little's Law in full, with a calculator.
• Performance vs scalability — the per-system version of the same trade-off.
• Availability patterns — the math behind nines.
• System-design playbook — 19 worked problems applying these numbers in full.
• Performance methods (RED, USE) — what to measure once you've sized.
• Paper — The Tail at Scale on why P99 matters more than the median.
• Jeff Dean's original latency-numbers gist
• Simon Eskildsen's napkin-math repo — the canonical practice exercises.