Capacity planning done as simple division produces a design that fails at the load it was sized for. If a server can handle a hundred requests a second, ninety a second seems comfortable, and it is not. Whenever work arrives irregularly, some of it arrives while the previous piece is still being served, and that waiting grows in a way that is not proportional to load. As the share of time the resource is busy climbs toward one, the queue in front of it grows toward infinity, and the growth is violent at the end: for a simple single-server queue, going from fifty to seventy-five percent busy roughly doubles the time in system, but going from ninety to ninety-five percent doubles it again over a much smaller step in load. The consequence for a design is that the last ten percent of a resource is not usable capacity, it is the reserve that keeps response times finite when arrivals bunch up. So a capacity plan states a target utilization well below one, sized so that the tail of the response time still meets its requirement, and treats the remainder as headroom for bursts, for failover of a lost instance, and for the slower service times that arrive with a bad release. You can now defend a target utilization number instead of dividing load by capacity.
Utilization (ρ) is a queueing theory metric defined as the ratio of arrival rate (λ) to service rate (μ), quantifying the fraction of a system's maximum processing capacity currently in use. As utili…