Capacity Estimation

First PublishedMay 5, 2026ByAtif Alam

Capacity work in design reviews answers “will anything obviously catch fire under expected load?” Useful estimates are honest about uncertainty; precision without data is misleading.

Working Formulas

Queries per second (QPS) from daily activity:

QPS ≈ DAU × actions_per_user_day / 86400

Use peak multipliers when you know them (often several times average for bursty products).

Writes are often 1–10% of read operations for many consumer-style systems, but billing, logging, and IoT-style ingress can invert that. Validate with product expectations and requirements.

Storage over a horizon:

Storage ≈ row_count × average_row_bytes × retention_multiplier

Account for indexes, replication copies, and backups separately when discussing cost, not just primary sets.

Egress or ingress bandwidth:

Bandwidth ≈ QPS × average_payload_bytes

Include fan-out if one user action triggers multiple internal calls.

Reasoning Versus Precision

Stakeholders rarely need six significant figures; they need which resource exhausts first — CPU on stateless tiers, disk IOPS on the database, hot keys in cache, outbound bandwidth at the edge. Call out assumed payload sizes and cache hit rates so others can challenge them.

Find the Bottleneck First

Identify the dominant constraint before drawing a dozen microservices. If the bottleneck is clearly the relational primary under write load, replicas and CDN do not fix it; partitioning, queue-backed writes, or schema change might. Conversely, if reads dominate and are cacheable, read scaling and caching patterns merit earlier attention.

If two equally plausible bottleneck stories exist, list both and note what measurement would discriminate them.

Related: Read scaling, Write scaling, design review checklist, glossary (DAU, QPS).