Back-of-the-Envelope Estimation

TL;DR: You do not need three significant figures. You need the right order of magnitude in under three minutes. Memorize a handful of constants (10^5 seconds per day, 2^10 = 10^3, peak = 3 to 5x average), feed them through a DAU-to-QPS-to-storage pipeline, and you will know whether your system fits on a laptop, a rack, or a multi-region fleet. Shopify's 2024 BFCM peaked at 284 million requests per minute on edge^[1], and that number was predicted months earlier by exactly this kind of math.

Learning Objectives#

After this module, you will be able to:

• Recite the powers-of-2 table up to 2^50 and convert to decimal equivalents instantly
• Convert DAU into average QPS, peak QPS, bandwidth, and storage in under 3 minutes
• Apply peak multipliers (2x to 10x) appropriate to the service class
• Account for replication, indexes, and backups when sizing storage
• Distinguish bits from bytes and avoid the 8x error in bandwidth estimates
• Produce a defensible capacity estimate for a Twitter-scale or WhatsApp-scale system

Intuition#

At the University of Chicago in the 1940s, Enrico Fermi famously asked his students: "How many piano tuners are in Chicago?"^[2] Nobody knew the answer. That was the point. Fermi showed that by chaining a few reasonable assumptions (population of Chicago, fraction of households with pianos, tuning frequency, hours per tuning, working hours per tuner), you could land within 2x of the real number in under a minute. No research required. Just multiplication.

System design estimation is the same discipline. You are not computing a budget with accountant precision. You are answering: "Does this fit on one server, one rack, or a datacenter?" The answer to that question changes your architecture. The difference between 10 TB and 10 PB is the difference between "buy a bigger disk" and "design a sharding strategy." The difference between 10 PB and 10 EB is the difference between "shard" and "redesign from scratch."

Rounding 86,400 seconds per day to 10^5 introduces 15% error. Rounding 2^20 to 10^6 introduces 5% error. Stacked across a full estimate, these compound to about 25% at petabyte scale^[3]. That is fine. No architecture decision turns on 25%. Every architecture decision turns on 10x.

The opposite failure is worse: spending 20 minutes computing 169,722 QPS exactly instead of saying "about 150K" and moving on to the design.

Theory#

Powers of ten you must memorize#

These are the constants that make estimation fast. Memorize them once; use them for a career.

Time constants:

• 1 day = 86,400 s. Round to 10^5 (15% error, always acceptable).
• 1 year = 31.5M s. Round to 3 x 10^7.
• 1 month = 2.6M s. Round to 2.5 x 10^6.

Population anchors:

• World: 8 billion. Smartphone users: 5 billion.
• Facebook DAU: 2.1 billion^[4]. YouTube MAU: 2.7 billion.
• WhatsApp messages/day: 100 billion (2024)^[5].

The latency hierarchy#

Jeff Dean's "Numbers Every Programmer Should Know" spans nearly nine orders of magnitude^[6][7]. Latency and Throughput covers this in detail. For estimation, memorize the anchors:

Each hop in the latency hierarchy is 10x to 1,000x slower than the previous; this shape has barely changed since 2012 because memory and light-speed are physical limits^[8].

The key insight for estimation: if your design requires a cross-datacenter round trip per request, your latency floor is 150 ms. No optimization can fix physics.

QPS estimation#

The formula:

avg_QPS = DAU x requests_per_user_per_day / 10^5
peak_QPS = avg_QPS x peak_multiplier

Peak multipliers by service class (sourced from real events):

The five-step pipeline from population to capacity budget. Every estimate follows this path; the three multipliers (peak, replication, retention) are where most people under-count.

Worked example: Twitter in 2013 had 150M DAU and 300,000 QPS for timeline reads vs 6,000 QPS for writes (a 50:1 read-heavy ratio)^[9:1]. Let us verify:

Write QPS check: 400M tweets/day / 10^5 = 4,000 TPS avg
Peak write: 4,000 x 2.5 = 10,000 TPS (matches reported 6K-12K range)
Read QPS: 150M x 200 reads/day / 10^5 = 300,000 QPS (exact match)

Storage estimation#

Formula: records_per_day x bytes_per_record x retention_days x replication_factor x 1.3 (indexes)

The multipliers people forget:

• Replication factor: 3x is table stakes for Cassandra, ScyllaDB, DynamoDB, HDFS^[11].
• Index overhead: 1.3 to 1.5x for secondary indexes, bloom filters, tombstones^[11:1].
• Backups: 2 to 5x the primary store depending on retention policy^[1:2].

Discord illustrates every multiplier. In 2022 they had trillions of messages on 177 Cassandra nodes. After migrating to ScyllaDB with RF=3, they landed on 72 nodes at 9 TB each, totaling ~650 TB of replicated message data^[11:2].

Per-object size reference:

Bandwidth estimation#

Formula: peak_QPS x avg_payload_size

Critical unit trap: 1 Gbps = 125 MB/s, not 1 GB/s. Network engineers use bits; storage engineers use bytes. Confusing them inflates your capacity estimate by 8x^[7:1].

AWS egress pricing (us-east-1, 2025): first 100 GB/month free, then $0.09/GB for the next 10 TB, tiered down to $0.05/GB over 150 TB^[12][13]. Cross-AZ traffic costs $0.01/GB each way, which adds up fast in microservice architectures where inter-service calls can significantly exceed external egress^[12:1].

YouTube sanity check: 2.7B MAU, ~1B DAU-equivalent, 30 min/day at 2 Mbps average = ~20M avg concurrent streams. At 3x peak = 60M concurrent x 2 Mbps = an estimated 120 Tbps peak egress^[14]. That is why Google's Edge Network serves content from 100+ CDN cache locations across metro areas worldwide, plus a much larger set of peering edge PoPs^[15].

Memory and CPU sizing#

Redis per-key overhead: Each key carries 50 to 100 bytes of metadata (pointers, type tag, expiration) beyond the value itself^[16]. For 10M small keys, that is 500 MB to 1 GB of overhead before any data is stored. Redis hash encoding (listpack) yields up to 10x memory savings for small collections, with 5x being typical^[17].

Cache sizing rule: working_set x 1.2 is the standard LRU target. If eviction rate exceeds 1%, add memory or reduce key cardinality.

Thread count heuristic: For CPU-bound work, use N_cores threads. For I/O-bound work, use 2 to 4x N_cores (the classic CPU x (1 + wait_time/compute_time) formula).

The multiplier stack that turns a naive estimate into a real one. Missing any single multiplier under-counts by 2 to 5x; missing two puts you off by an order of magnitude.

Real-World Example#

Twitter timeline fanout (2013)#

Raffi Krikorian's 2013 QCon talk^[18] is the canonical worked example of estimation meeting production. Let us walk through the full math and see how it drove architecture.

Given numbers (2013):

• 150M DAU, 400M tweets/day^[9:2]
• 300K QPS timeline reads, 6K QPS writes (50:1 read-heavy)^[9:3]
• 22 MB/s firehose (all public tweets)^[9:4]
• Home timeline: 30 billion deliveries/day^[9:5]

Storage estimate:

Tweets/day: 400M = 4 x 10^8
Bytes/tweet: ~1 KB (280 chars + metadata + media pointers)
Raw/day: 4 x 10^8 x 10^3 = 4 x 10^11 B = 400 GB/day
Per year: 400 GB x 365 = 146 TB/year
Replicated (3x): ~450 TB/year
With indexes (1.3x): ~585 TB/year. Round to 600 TB/year.

Fanout cost (the hard part):

Each tweet must be delivered to every active follower's timeline cache. Twitter stored timeline IDs in Redis: 800 entries per user, each entry 12 bytes (8-byte tweet ID + 4-byte flags)^[9:6].

Avg followers: ~200 (median much lower, but celebrities skew)
Fanout writes/tweet: 200 Redis list inserts (average case)
Total fanout writes/day: 400M tweets x 200 = 80 billion Redis inserts
Fanout QPS: 80B / 10^5 = 800K Redis writes/sec

This is enormous. And it gets worse for celebrities. A single tweet from a user with 20M followers means 20M Redis inserts. At p50 delivery time of 3.5 seconds to 1M followers, the queue depth for a celebrity tweet is catastrophic^[9:7].

The architecture decision this math forced:

• Fanout-on-write for normal users (pre-compute timelines, O(1) reads)
• Fanout-on-read for the top celebrity cohort (merge at read time, avoid 20M writes)
• Only active users (logged in within 30 days) get cached timelines^[9:8]

Twitter's hybrid fanout: write-amplification for normal users buys O(1) read latency; celebrities switch to read-time merge to avoid 20M+ Redis inserts per tweet.

The "fail whale" era was directly traceable to celebrity fanout: replies arriving before the original tweet because the fanout queue had not drained^[9:9]. The 2014 pivot to read-time merge for top accounts was the fix that BOE math predicted.

Trade-offs#

This chapter teaches a method, not a menu of substitutable designs, so there is no comparable-alternatives table here. The two decisions that look tabular (fanout-on-write vs fanout-on-read and the two main estimation heuristics) are covered inline above:

• Fanout-on-write vs fanout-on-read is the architectural choice the Twitter example in § Real-World Example walks through, with the celebrity-threshold cutover as the empirical rule^[9:10][18:1].
• Estimation heuristics (over-estimate by ~10x for early-stage uncertainty; round to powers of 10 for speed, accepting ~25% compounded error at PB scale) are applied throughout § Theory and § Storage estimation.

Treat these as method, not options to pick between.

Common Pitfalls#

Exercise#

Design Challenge: Estimate storage, bandwidth, and server count for a messaging app like WhatsApp: 3 billion MAU, 100 billion messages/day, 1 KB average message size. Show the math step by step.

Messages/day: 100B = 10^11
Avg write QPS: 10^11 / 10^5 = 10^6 = 1M messages/sec
Peak write QPS (3x): 3M messages/sec

Raw bytes/day: 10^11 messages x 1 KB = 10^14 B = 100 TB/day
Replicated (RF=3): 300 TB/day
With indexes (1.3x): 390 TB/day. Round to 400 TB/day.

Per year: 400 TB/day x 365 = 146 PB/year. Round to 150 PB/year.
5-year retention: 750 PB = 0.75 EB

Write ingress: 3M msg/sec x 1 KB = 3 GB/s = 24 Gbps peak
Read egress (assume each message read 1.5x on average for group chats):
  = 3M x 1.5 x 1 KB = 4.5 GB/s = 36 Gbps peak
Total: ~60 Gbps peak, distributed across regions.

Assume 8 TB usable per node (ScyllaDB/Cassandra class):
Daily growth: 400 TB/day / 8 TB = 50 new nodes per day just for growth
Steady-state for 1 year of hot data: 150 PB / 8 TB = ~18,750 nodes

30-day hot storage: 400 TB/day x 30 = 12 PB
Nodes: 12 PB / 8 TB = 1,500 nodes (much more reasonable)

Key Takeaways#

• Always estimate. Even a 60-second pass prevents choosing the wrong architecture class (single server, sharded cluster, multi-region fleet).
• Estimate in under 3 minutes. Order of magnitude is the goal. 150K QPS vs 170K QPS changes nothing; 150K vs 1.5M changes everything.
• Memorize the constants: 10^5 s/day, 3 x 10^7 s/year, 2^10 = 10^3, 2^40 = 1 TB.
• Use the pipeline: DAU to QPS to bandwidth to storage. Walk it top to bottom every time.
• Always apply the multiplier stack: peak (3 to 5x), replication (3x), indexes (1.3x), backups (2 to 5x). Missing one is the single most common estimation failure.
• Peak multipliers are evidence-based: Shopify BFCM 4.7M RPS^[1:5], Twitter World Cup 618K TPM^[10:1].
• Bits vs bytes is an 8x error. Write the unit. Always.
• The estimate's job is to pick the architecture class (single server, sharded cluster, multi-region fleet), not to produce a purchase order.

Further Reading#

• Jeff Dean, "Building Software Systems at Google and Lessons Learned" - The Stanford CS295 talk where the latency numbers were first widely circulated; the origin of every estimation table you have seen.
• Jonas Boner, "Latency Numbers Every Programmer Should Know" - The canonical gist, last updated 2024, with community discussion on which numbers have drifted.
• Colin Scott, Interactive Latency - Animated visualization showing how Dean's numbers drift over time; proves that RAM and cross-continent RTT are pinned by physics.
• Raffi Krikorian, "Timelines at Scale" (InfoQ 2013) - The canonical Twitter fanout talk with exact QPS, storage, and delivery-time numbers.
• Discord, "How Discord Stores Trillions of Messages" - Storage BOE math validated in production: node counts, latencies, replication factors, and migration speeds.
• Shopify Engineering, "How we prepare Shopify for BFCM" - Modern peak-capacity planning with 2024 numbers (284M RPM edge, 12 TB/min, 57.3 PB total).
• Sirupsen, Napkin Math - Monthly practice problems for estimation with first-principles code checks; the best way to build estimation muscle.
• Brendan Gregg, The USE Method - Utilization/saturation/errors checklist for sanity-checking estimates against production bottlenecks.
• Redis Memory Optimization - Listpack encoding thresholds and hash patterns for cache sizing; essential when your estimate says "we need 50M keys in Redis."

Flashcards#

References#