ScaleWiki · hands-on system design

Capacity planning lab

A cache can make your normal workload look small while hiding a much larger failure case. Build a first estimate, see where requests go, and compare what happens when a node fails or the cache stops helping.

This original ScaleWiki workbench explains its own arithmetic. It is an educational model for framing a load test, not a hardware benchmark, price quote, or availability guarantee.

Set a workload, then test its assumptions

These presets are invented learning scenarios, not hardware benchmarks. Replace the node throughput with a measurement from your service. Calculations run in your browser; this planner does not send or save your inputs.

Current scenario: Small read-heavy example

1. Describe your workload

Average incoming requestsrequests / second

The average over a full day, including quiet periods. Zero is allowed.

Peak traffic multiplier× daily average

A short peak determines serving capacity; it does not multiply a full day of storage.

Requests that are reads% of all requests

The rest are writes. The same mix is assumed at average and peak traffic.

Read cache hit rate% of reads

Only cache hits on reads avoid origin work. Writes always reach the origin.

New stored data per writekB (1,000 bytes)

Net new retained bytes per write, before replicas. Include metadata if known; use 0 for no growth.

Retention perioddays

A steady retention window with prompt deletion. Zero means no retained data in this model.

Total stored copiescopies, including primary

Three means one primary plus two replicas. Backups and indexes are additional.

Measured sustainable node throughputorigin requests / second

Replace the example with a load-test result for your actual read/write mix and latency target.

Fraction of measured capacity to use% of measured throughput

A planning margin, not a predicted CPU utilization. 70% reserves 30% of measured throughput.

2. Read the estimate

Incoming requests / day: 8,640,000; 864,000 writes per day
Peak origin requests / second: 140; 500 incoming at peak
Origin nodes with spare capacity: 2; 1 needed to serve + 1 spare
Retained data, all copies: 155.52 GB; 30 days × 3 stored copies

Where peak requests go

Reads served by cache: 360 / s
Read misses to origin: 90 / s
Writes to origin: 50 / s

Cache capacity still needs its own plan. A cache hit is assumed to bypass the origin tier entirely; this does not apply if that tier must authenticate or process every request first.

Storage grows with writes

New data / day, one copy: 1.728 GB
New data / day, all copies: 5.184 GB
Retained data, one copy: 51.84 GB
Retained data, all copies: 155.52 GB

Decimal units: 1 kB = 1,000 bytes; 1 GB = 1 billion bytes. Retained data excludes indexes, logs, backups, compression, and spare disk space. It is not a disk purchase recommendation.

3. Stress the plan

One origin node goes away

With all 2 nodes sharing load, each handles about 70 requests/s. After losing one, each remaining node handles 140 requests/s, against a planning limit of 210.

The spare may serve traffic normally. This arithmetic assumes immediate, even redistribution and covers one node, not a zone failure or a database quorum.

The cache becomes cold

At a 0% hit rate, all 500 peak requests/s reach the origin. At the same measured throughput, that needs 4 nodes including a spare: 2 more than the warm-cache plan.

Cold-cache work may also cost more per request. Load-test that case separately; consider prewarming, request coalescing, rate limits, and a degraded response.

4. Check every equation

Percentages are divided by 100 below. “Round up” means the next whole node. Rounded display values are never used as calculation inputs.

Daily incoming requests: 100 × 86,400 = 8,640,000 requests
Peak incoming traffic: 100 × 5 = 500 requests/s
Peak origin traffic = writes + read misses: 500 × [(1 − 0.9) + 0.9 × (1 − 0.8)] = 140 requests/s
Allowed throughput per node: 300 × 0.7 = 210 requests/s
Serving nodes, before the spare: Round up (140 ÷ 210) = 1 nodes. Add one if the result is greater than zero.
New logical storage each day: 8,640,000 × (1 − 0.9) × 2 × 1,000 = 1,728,000,000 bytes
Retained storage across all copies: 1,728,000,000 × 30 × 3 = 155,520,000,000 bytes

Turn the estimate into an experiment

Measure the workload. Record a full traffic cycle, the read/write mix, and the cache hit rate. Averages can hide a hot key or one unusually expensive endpoint.
Find sustainable throughput. Replay a representative request mix against one node. Stop increasing load when your latency or error target fails. Repeat with production-like data, dependencies, and cache state.
Test the failure case. Use the calculated count as a starting hypothesis. Remove one node under peak traffic and check tail latency, errors, queue growth, database limits, and recovery time.
Account for what is missing. This model omits retries, fan-out, request cost differences, autoscaling delay, uneven partitions, network limits, and database replication work. Add separate budgets for those constraints.

Connect the estimate to scaling choices

Why the assumptions matter

Requests per second are useful for this first calculation only when requests have comparable costs. Google's SRE chapter explains why capacity also needs resource measurements; AWS's caching guidance explores the operational risks of depending on cache hits. These sources inform the cautions here; the presets and calculations are ScaleWiki's illustrative model.

Google SRE: Handling Overload — why request cost and bottlenecks change the meaning of throughput.
AWS Builders' Library: Caching challenges and strategies — cache dependence, failure behavior, and operational trade-offs.

Found a calculation issue? Send the inputs and expected result so the model can be checked.