Everything downstream hangs off peak RPS, so get it first. The only constant you need is 86,400 seconds in a day, round it to 100,000 and your numbers land within 15%, which is well inside the error bars of every other guess you are making.

Size for peak, not average. A system sized for the mean is down every evening.

Storage is a flow problem, not a stock problem: bytes per day, times days. The two multipliers people forget sit on either side of that: compression divides the size, while indexes and replication multiply it back up.

With growth g, cumulative years form a geometric series, not a straight multiply: Y1 × ((1+g)^N − 1) / g. At 30% growth, five years comes out to 9.0 first-years, not 5.

A cache only ever helps the read path, and only for data that gets read again before it changes. It doesn't reduce how much data exists, it reduces how often you have to go get it, which is why the two numbers that matter are the hit ratio (how much traffic it absorbs) and the working set (how much of the data has to stay hot to earn that hit ratio).

Real traffic is skewed, not uniform: a small slice of keys usually accounts for most reads. That's what makes caching cheap, you're not memory-provisioning for the whole dataset, just its hot tail. Get the working-set estimate wrong, low, and you'll see a hit ratio that never reaches what you sized for.

Bandwidth has the same peak-vs-average split as everything else in this tool, but it shows up twice: the peak figure is what you provision, the link speed and NIC capacity that has to survive your busiest second. The monthly transfer figure is what you get billed for, built from average traffic over the whole month, not the peak.

CDN offload and cache hit ratio look similar but solve different problems: caching keeps repeat reads off your database while still serving them from your own servers, so they still count as egress here. A CDN in front of that serves some of those reads from the edge instead, so they never touch your origin's network at all, that's the traffic this tab actually removes.

Two different laws, two different answers, and mixing them up is the classic mistake. Throughput is bounded by CPU work: a core does 1000 ÷ cpu-ms requests per second. Concurrency is Little's Law, L = λ × W, a request waiting 200ms on a database still occupies a thread even though it burns no CPU. That's why an I/O-heavy service needs many more threads than cores.

Utilisation is where queueing theory bites. For an M/M/1 queue, latency scales as 1 / (1 − ρ). At 50% load you wait 2× service time; at 90% you wait 10×; at 99% you wait 100×. Nothing changed about the server, only how full it is.

Shard count is the maximum of two independent constraints: how much data fits, and how much traffic a node takes. Sizing on storage alone is how you end up with fat, idle shards that still fall over.

Averages lie about shards. A uniform split assumes uniform keys, and real keys are Zipfian, one celebrity, one popular product, one busy tenant. Estimate your hottest shard at several times the mean and check that number instead.

A log is a buffer, and buffers have three numbers: fill rate, drain rate, and depth. Partition count is set by the greater of raw throughput and consumer parallelism, because one partition can only be read by one consumer in a group, partitions are the ceiling on how wide you can scale reads.

The number people skip is drain time. If consumers run at 1.1× the produce rate, a 30-minute outage takes five hours to clear. Recovery headroom is a design parameter, not an accident.

Latency does not average, it accumulates on the critical path and then gets amplified at the tail.

The single biggest lever is round trips, not milliseconds of compute. Three sequential database queries at 15 ms cost more than every line of your application code. Parallelise what you can, batch the rest, and count the hops before you optimise a loop.

Physics sets a floor you cannot code around: light in fibre travels about 200 km/ms, so a round trip across the Atlantic is ~70 ms no matter what runs at either end.

Availability composes in two directions. Dependencies in series multiply: five services at 99.95% each give you 99.75%, worse than any single part. Redundant copies in parallel multiply the failure probability instead, which is why two 99% replicas give 99.99%.

The catch is independence. Two replicas sharing a power feed, a deploy pipeline or a config store fail together, and the arithmetic quietly stops applying.

Cost estimates are for shape, not procurement, they tell you which component you should be arguing about. In most designs one line dominates by an order of magnitude, and it is usually egress or storage rather than compute.

Two derived numbers matter more than the total: cost per user and cost per million requests. Those are the ones that have to sit below revenue per user, and they are what turn an architecture debate into a business one.