Filter concepts by levelShowing all levels.

System Design · Back-of-the-Envelope Math

Back-of-the-Envelope Math

Seven quantities, the conversions behind them, and knowing which guess actually decides the answer

  • Seven quantitiesbandwidth, storage, memory, cache, queue, CPU, IOPS
  • Bits vs byteslinks are bits, storage is bytes — ÷8
  • Peak vs growthpeak is once, growth compounds
  • Dominant assumptionthe widest-range guess decides the result

1.What a back-of-the-envelope estimate covers

A back-of-the-envelope pass covers seven quantities: network bandwidth, storage, memory, cache size, queue depth, CPU needs and database IOPS — done fast, on the spot, with rounded numbers rather than a spreadsheet.

Key features

  • Seven quantities: bandwidth, storage, memory, cache size, queue depth, CPU, IOPS
  • CPU needs and database IOPS are the two beyond section 4's five request-facing categories
  • The goal is a fast, rounded estimate, not a precise one
  • Each quantity answers a different design question, not a substitute for the others

The seven back-of-the-envelope quantities

The seven back-of-the-envelope quantities
QuantityAnswersRough method
Network bandwidthwill the link saturate?RPS × avg payload size, in bits
Storagehow much disk, and for how long?records × size × retention
Memorywhat fits in RAM?working-set size, not total data size
Cache sizehow big a cache actually helps?hot subset × item size
Queue depthis the queue keeping up?arrival rate vs service rate
CPU needshow many cores at 100% util?work per request × RPS
Database IOPSwill the disk be the bottleneck?reads/sec + writes/sec to disk
The seven quantities, grouped by the resource each one bounds

Over the wire

Network bandwidth

RPS x average payload, converted to bits — links are rated in bits per second

On disk

Storage

records x size x retention

Database IOPS

reads/sec plus writes/sec that actually reach the disk, after the cache

In RAM

Memory

the working set, not the total data size

Cache size

hot subset x item size

Work per second

CPU needs

work per request x RPS, read as cores at 100% utilisation

Queue depth

arrival rate against service rate

  • Seven quantities, rounded, on the spot
  • Over the wire
    • Network bandwidth — RPS x average payload, converted to bits — links are rated in bits per second
  • On disk
    • Storage — records x size x retention
    • Database IOPS — reads/sec plus writes/sec that actually reach the disk, after the cache
  • In RAM
    • Memory — the working set, not the total data size
    • Cache size — hot subset x item size
  • Work per second
    • CPU needs — work per request x RPS, read as cores at 100% utilisation
    • Queue depth — arrival rate against service rate

Command

text
Seven quantities, on the spot, rounded:
  bandwidth · storage · memory · cache size
  queue depth · CPU needs · database IOPS

Seven quantities for a fast estimate: bandwidth, storage, memory, cache size, queue depth, CPU needs, database IOPS.

2.The unit conversions every estimate depends on

Every capacity number rests on two conversions: the 1,024-based ladder from bytes to KB/MB/GB/TB, and bits vs bytes — network links are rated in bits per second, but storage and payload sizes are almost always given in bytes.

Key features

  • 1 byte = 8 bits — the single most common source of a 8x estimation error
  • 1 KB = 1,024 B; 1 MB = 1,024 KB; 1 GB = 1,024 MB; 1 TB = 1,024 GB
  • Network links are rated in bits/sec; storage and payloads are almost always bytes
  • 1 day = 86,400 seconds; 1 month ≈ 2,592,000 seconds (30-day approximation)

The conversion ladder

The conversion ladder
FromToFactor
BytesBits× 8
KBBytes× 1,024
MBKB× 1,024
GBMB× 1,024
TBGB× 1,024
DaySeconds× 86,400
Month (30d)Seconds× 2,592,000
A 100 Mbps link, converted to bytes/sec

100 Mbps

100,000,000 bits/sec

÷ 8

bits -> bytes

12.5 MB/sec

12,500,000 bytes/sec

  1. 100 Mbps — 100,000,000 bits/sec
  2. ÷ 8 — bits -> bytes
  3. 12.5 MB/sec — 12,500,000 bytes/sec

Command

text
bytes = bits / 8
KB = bytes / 1,024
MB = KB / 1,024
GB = MB / 1,024
seconds/day   = 86,400
seconds/month ≈ 2,592,000  // 30-day approximation

1 byte = 8 bits (network links are bits, storage is bytes); 1 KB/MB/GB/TB step is ×1,024; 1 day = 86,400 seconds.

3.Peak-to-average ratios and growth over time

A single estimate answers "what does the system need today, at peak" — but a design also has to survive the same system six or twelve months from now, which means applying a growth rate on top, not just a peak factor.

Key features

  • Peak-to-average is a same-day multiplier: peak RPS = average RPS × peak factor
  • Growth compounds: size after N months = today's size × (1 + rate)^N, not a flat addition
  • 10%/month compounding growth reaches roughly 3.1x in 12 months, not 2.2x
  • A design should be checked against both today's peak and a future, grown peak

Compounding growth at 10%/month, starting from 100 GB

Compounding growth at 10%/month, starting from 100 GB
MonthFormulaSize
0 (today)100 × 1.10^0100 GB
3100 × 1.10^3≈ 133 GB
6100 × 1.10^6≈ 177 GB
12100 × 1.10^12≈ 314 GB
Compounding against adding flatly — 100 GB at 10% a month

Both lines are computed from the two formulas, not measured. They are indistinguishable for the first quarter, which is what makes the flat guess feel safe; by month 12 they are 94 GB apart (314 against 220) and the gap widens every month after.

  • 0: Compounded — 100 x 1.10^N 100, Flat guess — 100 + 10N 100
  • 3: Compounded — 100 x 1.10^N 133, Flat guess — 100 + 10N 130
  • 6: Compounded — 100 x 1.10^N 177, Flat guess — 100 + 10N 160
  • 9: Compounded — 100 x 1.10^N 236, Flat guess — 100 + 10N 190
  • 12: Compounded — 100 x 1.10^N 314, Flat guess — 100 + 10N 220

Command

text
peak_rps      = average_rps * peak_factor
size(months)  = today_size * (1 + monthly_growth_rate) ** months

Peak RPS = average × peak factor, applied once; growth compounds — size after N months = today × (1 + rate)^N, not a flat sum.

4.Knowing which assumptions dominate the result

Every estimate rests on a handful of guessed inputs, but they rarely matter equally — one or two dominate the final number, and those are the ones worth stress-testing, not every input treated as equally uncertain.

Key features

  • An estimate is only as solid as its least-certain input, not its average certainty
  • The dominant assumption is the one with the widest plausible range, not the largest value
  • State an estimate as a range or with its dominant assumption named, not a bare number
  • Re-running the estimate at the dominant assumption's low/high end shows the real spread

Same estimate, three assumptions of very different confidence

Same estimate, three assumptions of very different confidence
AssumptionConfidencePlausible range
Requests/day (from analytics)high — measured100M ± 5%
Average payload size (measured)high — measured4 KB ± 10%
Cache hit ratio (guessed, no cache built yet)low — guessed60%-95%
Finding the assumption that dominates a storage estimate

Log volume

50M events/day — measured, ±5%. Narrow range.

Event size

500 bytes — measured, ±10%. Narrow range.

Retention period

"probably 90 days" — guessed, ranges 30-365. This dominates.

Re-run at both ends

30 days ≈ 0.75 TB, 365 days ≈ 9.1 TB — state the range, not 2.25 TB alone.

  1. Log volume — 50M events/day — measured, ±5%. Narrow range.
  2. Event size — 500 bytes — measured, ±10%. Narrow range.
  3. Retention period — "probably 90 days" — guessed, ranges 30-365. This dominates.
  4. Re-run at both ends — 30 days ≈ 0.75 TB, 365 days ≈ 9.1 TB — state the range, not 2.25 TB alone.

Command

text
for each input:
  ask: how wide is the plausible range?
  the widest range = the dominant assumption
  re-run the estimate at its low and high ends

An estimate is as solid as its least-certain input — find the assumption with the widest plausible range and state the estimate as a range around it.

Remember

  • Seven quantities for a fast estimate: bandwidth, storage, memory, cache size, queue depth, CPU needs, database IOPS.
  • 1 byte = 8 bits (network links are bits, storage is bytes); 1 KB/MB/GB/TB step is ×1,024.
  • Peak RPS = average × peak factor, applied once; growth compounds — size(N months) = today × (1 + rate)^N.
  • An estimate is as solid as its least-certain input — name the assumption with the widest plausible range.

Pro tip

  • Treating a 1 Gbps link as 1,000 MB/sec instead of dividing by 8 overstates capacity by 8x.
  • A flat "10% × 12 months = 120% more" undercounts real compounding growth by a wide margin.

Next up

  • Latency and throughput
  • Availability, reliability and durability
  • SLIs, SLOs, SLAs and error budgets

Sources

  • System Design Primer — github.com/donnemartin/system-design-primer
  • Checked 2026-08-21

Spotted a mistake on this page? Tell us.

ReadSheet