Capacity Calculator

How it computes

Nine formulas, all of them arithmetic you could do on a whiteboard. They are written out here so you can check the tool rather than trust it.

requests/day   = DAU × requests per user per day
average QPS    = requests/day ÷ 86,400
peak QPS       = average QPS × peak multiplier
write QPS      = peak QPS × write share
read QPS       = peak QPS − write QPS
origin reads   = read QPS × (1 − cache hit rate)
peak egress    = peak QPS × response bytes × 8            (bits/second)
new data/day   = requests/day × write share × stored bytes per write
provisioned    = new data/day × retention × replicas × overhead
instances      = ⌈ peak QPS ÷ (RPS per instance × target utilisation) ⌉

There are 86,400 seconds in a day. That single number does most of the work in a capacity conversation, and it is the one worth memorising: one request per user per day, for one million users, is about 12 QPS.

Choosing the inputs

The output is only as good as the multipliers, and four of them are where estimates go wrong.

Peak-to-average multiplier

Average QPS is a fiction — nobody experiences the average. You provision for the peak.

The last row is why event-driven products need queues and admission control rather than more instances. You cannot buy your way to a 50x spike.

Response and record sizes

The stored bytes per write field is deliberately separate from the response size. A 40 KB response assembled from six tables might durably store 300 bytes. Conflating the two is the most common way storage estimates come out an order of magnitude high.

Storage overhead

The raw record size is never what you provision. Indexes, write-ahead logs, free-space targets, fragmentation and compaction headroom all sit on top.

Replication multiplies on top of that, and it is separate: three replicas of a 2x-overhead Postgres dataset is 6x the raw bytes before backups. Backups are extra again.

Requests per second per instance

The default of 500 assumes a modest, mostly I/O-bound service on a few cores. Reality varies by two orders of magnitude, so measure yours rather than accepting the default:

Then derate. Target utilisation of 60–70% is not waste — it is the space that absorbs GC pauses, deploy rollovers, a noisy neighbour and the loss of one availability zone. A fleet sized to 95% utilisation is a fleet with no capacity to fail in.

Where these estimates are wrong

Be honest about this in the design review rather than after the incident.

Uniform requests. The tool assumes every request costs the same. Real systems have an expensive minority — a search, a report, an export — that consumes most of the capacity while being a rounding error in the count. If one endpoint is 5% of traffic and 60% of CPU, size that endpoint separately.

Independent users. Real traffic is correlated. A push notification, a marketing email, a cron, or an outage recovery synchronises users into a spike no multiplier predicted. See thundering herd.

No retries. Under stress, every layer retries, and the load on a struggling dependency can be several times the nominal figure. Capacity plans that ignore retry amplification understate the failure case badly.

Steady-state growth. Retention is linear here. Products that succeed do not grow linearly, and products that pivot orphan the data model entirely.

Cache hit rate is an input, not a fact. It is measured, and it degrades — under a cold start, after a deploy, during a key-space change. Run the numbers again at a 0% hit rate and check that the origin survives. If it does not, the cache is load-bearing and needs to be treated as a dependency with its own availability target.

Using it in a design review

The value is not the number. It is which order of magnitude you land in, because that decides the shape:

The same applies to storage: 500 GB is a laptop, 50 TB is a cluster decision, 5 PB is a company strategy.

Pair the output with the data store selection matrix once you know the volumes, and with the SLO calculator once you know what availability you owe on top of it.