Capacity planning with real numbers
Work out how many servers you need, with headroom for peaks and failures.
Capacity planning answers a plain question: how many servers do we need? The method is the same as ordering food for a party. Estimate peak demand, find what one server can really do, add safety margin, and plan for the things that will go wrong. Guessing too low means outages at the worst moment; guessing too high wastes money.
Worked example: the dinner rush
Step 1 of 5
Estimate the peak
The delivery app has 2 million orders a month in the busy season, but traffic is lumpy. Suppose measurement shows the peak minute reaches 3,000 requests per second (about 3 times the daily average).
A second useful tool is Little's law: the number of requests in flight equals the arrival rate times the time each takes. At 3,000 requests per second and 100 ms per request, that is 3,000 × 0.1 = 300 concurrent requests. Spread over 10 servers, each handles about 30 at a time. If latency rises to 1 second, concurrency jumps tenfold to 3,000, which is how a slow dependency quietly exhausts thread pools and connection limits.
Capacity is not only web servers. Walk the whole path and find the first thing to saturate: the load balancer, the web tier, the cache, the database connections and the network. The weakest link sets the ceiling. A database that handles 6,000 queries per second cannot serve 10 web servers that each generate 1,000, so the plan must include read replicas or a cache.
Do the heavy requests fit?
Send a mixed workload (cost 1 and 6) to 4 servers with least connections and look at the peak number of requests in flight. Add or remove servers and see how peakActive moves.
- 6 cost, client u0
- 1 cost, client u1
- 1 cost, client u2
- 1 cost, client u3
- 6 cost, client u4
- 1 cost, client u5
- 1 cost, client u6
- 1 cost, client u7
- 6 cost, client u8
- 1 cost, client u9
- 1 cost, client u10
- 1 cost, client u11
- 6 cost, client u12
- 1 cost, client u13
- 1 cost, client u14
- 1 cost, client u15
Your turn
Redo the calculation for 6,000 req/s peak with servers that safely do 400 req/s, spread over 3 zones where you must survive losing one zone. How many servers in total?
Stuck? Work out how many are needed in the surviving zones first.
What to remember
Estimate peak demand, measure per-server capacity, and plan for about 60 percent utilisation.
Add spares for failure: N+1, or enough to survive losing a whole zone.
Little's law (in flight = rate × latency) shows how latency problems turn into concurrency problems.
Check every layer; the first to saturate sets the limit.