Queueing Delay
The time a request spends waiting rather than being served, which rises non-linearly as utilisation approaches capacity.
The single most useful piece of performance intuition available, and it is counter-intuitive enough that most capacity planning ignores it.
Queueing theory gives, for simple systems, a waiting time proportional to ρ/(1−ρ) where ρ is utilisation. The consequence: at 50% utilisation, waiting time roughly equals service time. At 80% it is four times service time. At 90%, nine times. At 95%, nineteen. The curve is a hyperbola, and near capacity a small increase in load produces a large increase in latency.
This is why systems appear fine and then collapse suddenly rather than degrading smoothly, and it is why "the servers are only at 85% CPU" is not the reassurance it sounds like.
Two corollaries with direct design value. Variability makes it worse: bursty arrivals and variable service times push the curve up further, so a workload with a long tail of expensive requests queues badly at utilisations that would be comfortable for uniform work. And a single shared queue outperforms multiple separate queues at the same total utilisation, which is the argument for a shared pool with intelligent dispatch over statically partitioned capacity — and the reason supermarkets adopted the single serpentine queue.
The planning conclusion: target utilisation in the 60% to 70% region for latency-sensitive services, and treat headroom as the price of predictable response rather than as waste.