Capacity Estimation cheat sheet · System Design

1.What to estimate before designing

Before choosing any component, a design needs five numbers: requests per second, storage growth, bandwidth, memory, and queue volume — each one rules out or rules in different infrastructure choices.

Key features

Requests per second sizes compute, load balancers and connection pools
Storage growth sizes database capacity, backups and retention cost
Bandwidth sizes network links, CDN spend and egress cost
Memory sizes caching layers and how much can be served without a database hit
Queue volume sizes message brokers and worker pool count

The five estimation categories

The five estimation categories
Category	What it sizes	Ignoring it means
Requests per second	compute, load balancers, connection pools	the API tier falls over under real load
Storage growth	database capacity, backup cost, retention	a disk fills up months after launch
Bandwidth	network links, CDN spend, egress cost	a cloud bill spikes with no design change
Memory	cache size, what avoids a database hit	the cache is too small to matter
Queue volume	message broker throughput, worker count	a queue backs up faster than it drains

Five numbers before any component is chosen

Requests/sec

sizes compute, load balancers

Storage growth

sizes database, backups

Bandwidth

sizes network, CDN

Memory

sizes caching

Queue volume

sizes broker, workers

Command

text

Five numbers, before any component is chosen:
  requests/sec   -> compute + load balancing
  storage growth -> database + backups
  bandwidth      -> network + CDN
  memory         -> caching
  queue volume   -> message broker + workers

Five numbers before any component: requests/sec, storage growth, bandwidth, memory, queue volume — each sizes a different part of the design.

2.The core capacity formulas

Three formulas cover most capacity estimates: average RPS is requests per day divided by 86,400 seconds; peak RPS multiplies that by a peak factor; storage multiplies record count by average size by a retention multiplier.

Key features

A day has 86,400 seconds — the constant behind every daily-to-per-second conversion
Average RPS = requests per day ÷ 86,400
Peak RPS = average RPS × peak factor (commonly 2x-5x)
Storage = records × average record size × retention multiplier
Retention multiplier covers indexes, replicas and headroom, not just raw bytes

The three core formulas

The three core formulas
Quantity	Formula	Worked example
Average RPS	requests/day ÷ 86,400	100M/day ÷ 86,400 ≈ 1,157 RPS
Peak RPS	average RPS × peak factor	1,157 × 3 ≈ 3,472 RPS
Storage (raw)	records × avg record size	10M records × 2 KB = 20 GB
Storage (with retention)	raw storage × retention multiplier	20 GB × 1.3 ≈ 24.8 GB

100M requests/day, peak factor 3x

Average RPS

100,000,000 ÷ 86,400 ≈ 1,157 RPS

Peak RPS

1,157 × 3 ≈ 3,472 RPS

Storage (raw)

10M records × 2 KB = 20 GB

Storage (with retention)

20 GB × 1.3 ≈ 24.8 GB

Command

text

average RPS = requests_per_day / 86400
peak RPS    = average RPS * peak_factor
storage     = records * avg_record_size * retention_multiplier

avg RPS = req/day ÷ 86,400; peak RPS = avg × peak factor; storage = records × size × retention multiplier.

3.Reads, writes, cache hits and growth

A single RPS number is not enough — splitting it into reads vs writes, subtracting what a cache absorbs, and multiplying storage growth by a replication factor turns one estimate into the numbers each component actually needs.

Key features

Read/write ratio splits one RPS total into two very different loads
Cache hit ratio is the fraction of reads a cache absorbs before they reach the database
Average payload size and attachment size scale bandwidth and storage differently
Replication factor multiplies raw storage — 3x replication means 3x the disk
Daily data growth is what tells you when storage needs partitioning or archiving

Second-layer estimates and their formulas

Second-layer estimates and their formulas
Quantity	Formula	Worked example
Reads/sec	total RPS × read fraction	5,000 × 0.8 = 4,000
Writes/sec	total RPS × write fraction	5,000 × 0.2 = 1,000
DB reads/sec	reads/sec × (1 − cache hit ratio)	4,000 × 0.2 = 800
Raw daily growth	writes/day × avg write size	86.4M writes × 1 KB ≈ 82.4 GB
Growth with replication	raw growth × replication factor	82.4 GB × 3 ≈ 247.2 GB

One RPS number, split into the three the database actually needs

Reads — 7,200/s

6,480/s never leave the cache

7,200 x 0.9 — the hit ratio is doing this much work

720/s reach the database

7,200 x (1 - 0.9). An order of magnitude below the 8,000 a naive estimate would provision for

Writes — 800/s

800/s reach the database

Every write is a database write. No hit ratio applies

69,120,000 writes/day

800 x 86,400

Storage growth

~263.7 GB/day raw

69.12M x 4 KB

~527.4 GB/day provisioned

x 2 replication — every byte is stored twice for durability

Command

text

reads/sec    = total RPS * read_fraction
writes/sec   = total RPS * write_fraction
db_reads/sec = reads/sec * (1 - cache_hit_ratio)
growth/day   = writes/day * avg_write_size * replication_factor

Split RPS into reads/writes, subtract the cache hit ratio for DB-facing reads, and multiply storage growth by the replication factor.

4.Powers-of-ten approximation

Dividing by 86,400 in your head is slow; dividing by 100,000 (roughly 86,400 rounded up) is fast and close enough for an interview or a first-pass estimate — 100M requests/day is roughly 1,000 RPS before refining to the real 1,157.

Key features

86,400 seconds/day is close enough to 100,000 (10^5) for quick mental math
Daily total ÷ 10^5 approximates average RPS by shifting a decimal point
The 10^5 shortcut overstates true RPS by about 15.7% (100,000 vs 86,400)
Use it for a fast first pass; use the exact ÷86,400 formula for the real number

Quick daily-total-to-RPS approximations

Quick daily-total-to-RPS approximations
Requests/day	Quick estimate (÷10^5)	Exact (÷86,400)
1,000,000 (10^6)	10 RPS	≈ 12 RPS
10,000,000 (10^7)	100 RPS	≈ 116 RPS
100,000,000 (10^8)	1,000 RPS	≈ 1,157 RPS
1,000,000,000 (10^9)	10,000 RPS	≈ 11,574 RPS

Why the shortcut works, and exactly how wrong it is

The two bars are drawn to scale: 86,400 is 86.4% of 100,000, so the shortcut always overstates RPS by the same 15.7%.

Command

text

quick avg RPS ≈ requests_per_day / 100,000   // 10^5, fast mental math
exact avg RPS  = requests_per_day / 86,400    // real answer, ~15.7% lower

86,400 ≈ 100,000 for quick mental math — daily total ÷ 10^5 gives a fast RPS estimate, about 15.7% under the exact ÷86,400 figure.

5.From estimate to infrastructure

A capacity estimate is only useful once it turns into a count — peak RPS divided by what one server can handle gives a server count. Naming a server count without this division is a guess wearing a number.

Key features

Server count = peak RPS ÷ RPS one server can handle, rounded up
A per-server capacity figure must come from a benchmark, not a guess
Headroom (commonly 20-30%) is added on top so peak load is not the ceiling
Storage node count = total storage ÷ disk capacity per node
Bandwidth translates into network tier and CDN choice, not server count

Estimate-to-infrastructure translations

Estimate-to-infrastructure translations
Estimate	Divided by	Gives
Peak RPS	RPS one app server handles (benchmarked)	app server count
Storage (with retention)	disk capacity per database node	database node count
Peak bandwidth	network tier capacity	network/CDN tier choice
Queue volume	jobs/sec one worker processes	worker pool size

Peak RPS to server count, with headroom

Peak RPS

3,472

Per-server capacity

500 RPS, benchmarked

Divide, round up

3,472 / 500 ≈ 6.9 -> 7

+25% headroom

7 × 1.25 ≈ 8.75 -> 9 servers

Command

text

server_count = ceil(peak_rps / rps_per_server * (1 + headroom))
node_count   = ceil(total_storage / disk_per_node)

Server count = peak RPS ÷ benchmarked RPS-per-server, rounded up, plus headroom — never a guessed round number.