Back-of-the-envelope estimation

An estimate is a product of stated assumptions, and its real output is not the number but the binding constraint: the resource that runs out first and decides the design.

Four templates

Everything is multiplied, nothing added. Name which template before computing.

Rounding

• Round every input to one significant figure; quote only one in the answer.
• 86,400 s/day -> 1e5 to reason (16% high), back to 86,400 the moment a number becomes a result (fleet, bill, headroom).
• 1 M/day -> 10/s · 1 B/day -> 10,000/s · seconds/month 2.6e6 -> 2.5e6.
• Byte units go up in thousands (1 KB = 1e3 B), never 1,024.
• Bits vs bytes: divide a bit rate by 8 for bytes. Missing this factor of 8 is the top units slip.
• Never round a power of two that fixes a bit width: 2^32 = 4.3e9, 2^41 ms = 69.7 yr. Those are exact capacities.

Sensitivity: rank by spread

• A factor 2x too high makes the answer exactly 2x too high, regardless of its size.
• Rank assumptions by spread (high/low ratio you’d defend), not by size. Widest spread owns the answer; state it with its range.
• Stated or chosen values (retention, replicas) add no uncertainty.
• An estimate is robust when its conclusion survives its own uncertainty, not when its number is accurate.

Latency numbers, and the rule each implies

• Two traps: 100 us SSD is per-request latency (NVMe does 500 k-1 M IOPS at high queue depth); 10 ms seek applies only to spinning disks.
• Memory is 100,000x faster than a disk seek -> read-heavy designs end in a cache.
• Sequential beats random; random throughput is block size / latency, so always quote the block size.

Cache leverage (hit rate h)

• Mean latency = h(cache) + (1-h)(db); DB load = QPS x (1-h), a line falling to zero.
• Reduction factor 1/(1-h) is a hyperbola that diverges: each extra nine of hit rate divides DB load by ten.
• The last fraction of a percent is most valuable and least material; a stampede (99% -> 90%) instantly 10x’s DB load.
• “Does it fit?” is the memory template: if the working set fits it’s a hit-rate problem, else a sharding problem.

The checklist

What am I sizing?  ->  state each assumption + low/high  ->  round to 1 sig fig
  ->  compute per-day, / 1e5 for per-second  ->  apply peak (2x smooth, 3x bursty, none if queued)
  ->  redo at 86,400 if reporting a fleet or bill  ->  apply replication + retention
  ->  Does the answer change the design?
        no  -> say so, move on
        yes -> name the constraint it exposed

Binding-constraint walk

Run every time; take whichever your arithmetic exhausts first (often not the one asked about):

• CPU (cycles/req x QPS vs cores) · memory · network bytes · disk bytes · disk IOPS
• descriptors/connections (concurrent sockets vs per-box ceiling, ~100 k-500 k)
• blast radius (what one machine’s death drops)

Sanity-check a number you can’t verify

• Recompute by a route sharing no step.
• Convert to a physical object: drives, racks, dollars (carry the conversion constant, not just the unit).
• Test against a bound you believe (a box has tens of GB RAM; a primary does thousands of writes/s).
• Check every ratio’s direction before its magnitude (reads > writes, media > text, peak > average).
• All four guard against the units slip: carry units on every line (1.1e17 B before 110 PB).

Numbers / defaults to memorize

• DAU 20% of registered · 5 sessions/user/day · 0.1 creates/user/day (-> 50:1-100:1 read:write).
• Commodity box 128 GB / 16 cores / 10 Gbps · drive ~20 TB · rack ~600 drives.
• CDN egress ~$0.02/GB · 1080p video ~3 Mbps · UUID 16 B binary / 36 B text · web page ~2 MB.
• Replication ~3x copies vs erasure coding ~1.5x; tier cold data to cheaper, slower storage.

Biggest mistake: computing a number that doesn’t change the design.