Quantitative Cheat Sheet

Unit anchors

Quantity	Decimal	Binary approximation / note
1 kB / KB	1,000 bytes	1 KiB = 1,024 bytes
1 MB	1,000,000 bytes	1 MiB = 1,048,576 bytes
1 GB	10⁹ bytes	1 GiB = 2³⁰ bytes
1 TB	10¹² bytes	1 TiB = 2⁴⁰ bytes
Day	86,400 seconds	Round to 100,000 for mental math, then refine
Month	~2.6 million seconds	30 days
Year	~31.5 million seconds	365 days

Always label whether a provider/product uses decimal or binary units when cost or capacity is close to a limit.

Request and traffic rates

average QPS = requests per day / 86,400
peak QPS = average QPS × peak factor
byte rate = request rate × encoded bytes per request
network bit rate = byte rate × 8

Example: 400 million reads/day ≈ 4,630 average reads/s. At a 12× peak, design for ~55,600/s before growth and failure headroom.

For bursty workloads, a daily average can be nearly useless. Ask for or assume:

• peak-to-average factor;
• burst duration;
• largest tenant/key contribution;
• read/write mix;
• retry and fan-out amplification.

Storage growth

raw daily bytes = writes/s × bytes/write × 86,400
retained raw = daily bytes × retention days
physical storage ≈ raw × replication/encoding × index factor × overhead

Example: 25,000 events/s × 900 bytes ≈ 22.5 MB/s ≈ 1.94 TB/day decimal. At 90 days, raw is ~175 TB. With 3× replication and 35% indexes/metadata/compression net factor, state the assumed combined multiplier rather than mixing unrelated percentages invisibly.

Storage checklist

• Original payload versus encoded/compressed payload.
• Primary rows/objects plus secondary indexes.
• Replication or erasure-coding overhead.
• Write-ahead logs, tombstones, old versions, compaction headroom.
• Backups and cross-region copies.
• Temporary migration/backfill/shuffle space.
• Growth during recovery or procurement lead time.

CPU capacity

core-seconds/s = QPS × CPU seconds/request
required cores = core-seconds/s / planned utilization
failure-adjusted capacity = required cores / remaining-capacity fraction

Example: 40,000 QPS × 2.5 ms CPU = 100 core-seconds/s. At 60% target utilization, ~167 cores. To survive loss of one of three equal zones without exceeding that target, provision 167 / (2/3) ≈ 251 cores before growth.

Distinguish CPU time from wall latency. An I/O-heavy request can take 500 ms while consuming only 2 ms of CPU, yet it retains memory/connections while waiting.

Little’s Law

L = λW

• L: average items in the system.
• λ: throughput/arrival rate.
• W: average time in the system.

At 10,000 requests/s and 200 ms mean latency, average in-flight requests are 2,000. At 50 KiB retained state each, that is ~98 MiB before connection stacks, queues, runtime overhead, and tail bursts.

Use Little’s Law for connections, queue depth, jobs, database sessions, and pipeline work-in-progress. It assumes a stable long-run system; a growing backlog is not in equilibrium.

Queue/backlog math

backlog growth rate = arrival rate − service rate
net drain rate = service rate − arrival rate
drain time = backlog / net drain rate
oldest-age growth ≈ 1 second per second while a strict FIFO head is not catching up

Example: arrivals 70k/s, processing 50k/s → +20k/s, 72 million/hour. After scaling to 110k/s while arrivals remain 70k/s, a 144 million backlog drains at 40k/s in one hour ideally.

Include retry rate. If 15% of attempts retry once, effective work is at least 1.15×, often more when failures correlate.

Bandwidth and packet/operation rate

payload throughput = operations/s × payload bytes
wire throughput > payload due to headers, TLS, framing, retransmission

A 10 Gb/s link is 1.25 GB/s theoretical before overhead. A system can saturate CPU or packet rate with tiny messages while using little bandwidth; large streams can saturate bandwidth with modest request count. Calculate both operations/s and bytes/s.

Transfer time

ideal time = bytes / effective bytes per second
net catch-up rate = apply/copy rate − ongoing generation rate
catch-up time = backlog bytes / net catch-up rate

If a replica applies 160 MiB/s and new log arrives at 130 MiB/s, only 30 MiB/s reduces backlog. A 1 TiB lag takes roughly 9.7 hours in the ideal case.

Network latency decomposition

response time ≈ queueing + connection/TLS setup + network RTTs + server time + downstream RTTs + transfer time

Do not memorize nanosecond tables as exact facts. Use the stable ordering: cache < memory < local storage < same-zone network < cross-region network, and measure the actual environment.

For a sequential chain of dependencies, latencies add. For parallel fan-out, the slowest required branch dominates plus merge time.

Fan-out tail probability

If a request needs every one of n independent shards and each meets its deadline with probability p:

P(all succeed) = p^n

At p = 99.9% and n = 100, all-shard deadline success is about 90.5%. Independence is optimistic, but the equation demonstrates why broad scatter-gather harms tails. Use fewer shards, precomputed indexes, partial results, or different API semantics.

Availability composition

For serial critical dependencies with independent availability Aᵢ:

A_system ≈ product(Aᵢ)

Three serial services at 99.9% each yield roughly 99.7%, not 99.9%. Independence is rarely true; common dependencies and correlated deploys can be worse.

For parallel replicas where any one succeeds independently:

A_any = 1 − product(1 − Aᵢ)

For majority quorum, sum the probabilities of states with at least the required nodes. Then challenge the independence assumption and model zones, networks, software versions, and control planes.

Downtime intuition

Availability	Approx. downtime/year
99%	3.65 days
99.9%	8.76 hours
99.95%	4.38 hours
99.99%	52.6 minutes
99.999%	5.26 minutes

An SLO is usually measured over defined good events/time and can have exclusions or per-operation scopes. Use these figures only as intuition.

Cache impact

origin QPS = total QPS × (1 − hit ratio)
average latency ≈ hit ratio × hit latency + miss ratio × miss latency

At 200,000 reads/s and 98% hit ratio, origin sees 4,000/s. A drop to 90% sends 20,000/s—5× origin load. Provision and protect for miss storms, not just steady-state hits.

Effective hit ratio dimensions

Measure hit ratio by status code, tenant, route, object size, and byte hit ratio. A 99% request hit ratio can still have poor byte hit ratio if large objects miss. Negative cache hits may protect origin but can hide newly created data.

Partition/shard sizing

partitions needed = max(
    total QPS / safe QPS per partition,
    total byte rate / safe bytes per partition,
    total retained bytes / safe bytes per partition,
    required consumer parallelism
)

Then multiply/adjust for:

• hottest-key and tenant skew;
• largest failure domain;
• repair/compaction/migration;
• growth until next reshard;
• practical min/max partition count in the chosen system.

A good average does not protect one hot partition. Report max-to-mean and p99 partition load.

Replication and quorum intuition

For a simplified N-replica quorum system, R + W > N creates intersection between read and write sets. W > N/2 makes completed write quorums intersect. These are useful checks, not a full proof of linearizability. Membership, concurrent versions, failure acknowledgment, sloppy quorums, and read repair still matter.

For leader replication, quantify:

• copies that have persisted the write at client success;
• bytes/time lag for each replica;
• failover candidate’s durable/applied position;
• net catch-up and reseed thresholds.

Consistent hashing movement

In an ideal equal-weight balanced ring with N nodes, adding one node moves roughly 1/(N+1) of keys. Real moved bytes and QPS depend on token, value-size, and popularity skew. Virtual nodes improve granularity but increase metadata and movement complexity.

Rebalance time

move time ≈ bytes moved / throttled effective transfer rate

Include replica copies, checksums, ongoing writes, source/target disk, network, and foreground resource budget. Capacity expansion that begins at 90% disk is already late.

Object and media calculations

For direct upload/download systems calculate:

• average and p95 object size;
• upload/download concurrency;
• ingress/egress peak;
• multipart request count and retry bytes;
• CDN request and byte hit ratio;
• transformation amplification (original plus renditions);
• retention/version/cold-tier cost;
• restore throughput.

Example: 2 million 8 MiB images/day ≈ 15.3 TiB/day raw. Four renditions totaling another 5 MiB make 24.8 TiB/day. A 90-day hot-retention design is over 2 PiB before versions and replication.

WebSocket/long-lived connection capacity

connection memory = concurrent connections × bytes of state/connection
heartbeat rate = connections / heartbeat interval
reconnect rate after outage = connections / recovery window

Five million connections × 16 KiB state ≈ 76 GiB across the fleet before runtime/socket buffers. A 30-second heartbeat creates ~167k heartbeat events/s. Reconnecting all clients in one minute creates ~83k handshakes/s; use jitter, resumable state, and staged recovery.

B-tree and index intuition

A B-tree with fan-out f and height h can address on the order of f^h child/leaf positions. Wide keys reduce fan-out; random misses increase I/O. Index storage/write cost scales with indexed entries and page maintenance, not just lookup complexity.

Do not infer query performance from Big-O alone. Selectivity, clustering/locality, join cardinality, cache, row width, spills, and estimate quality dominate.

MapReduce/batch accounting

Track:

input bytes
map output bytes before/after combiner
shuffle network bytes
spill bytes and merge passes
reducer max/median bytes
final output bytes and file count

A job’s completion time is often set by the largest task/key, not total bytes divided by workers. Quantify skew and small-file overhead. For backfills, include ongoing data and downstream apply capacity.

Cost model template

Monthly cost ≈
  compute instance/core hours
+ provisioned/used memory
+ hot/warm/cold stored bytes
+ read/write/request operations
+ IOPS/throughput reservations
+ network egress and inter-region transfer
+ managed-service premiums
+ backup/version retention
+ observability volume
+ operational engineering cost/risk

State the dominant two units and one sensitivity: “A 10-point CDN hit-ratio drop increases origin egress by X,” or “doubling retention adds Y TiB and Z hours to restore.”

Estimation communication pattern

1. Write the equation with units.
2. Substitute rounded assumptions.
3. Calculate an order of magnitude.
4. Add peak, skew, replication, and failure headroom.
5. State the architecture decision it drives.
6. Name the production measurement that would replace the assumption.

Common quantitative mistakes

• Mixing bits and bytes or decimal and binary units.
• Applying replication twice or forgetting indexes/versions entirely.
• Using daily average as provisioned peak.
• Ignoring largest tenant/key and fan-out.
• Computing recovery from gross, not net, bandwidth.
• Treating 100% utilization as sustainable capacity.
• Assuming independent failures for replicas in one failure domain.
• Reporting average latency without queueing and p99.
• Adding consumers without checking downstream capacity.
• Giving a number that does not change any design choice.