Why queueing theory

You can use Kendall productively without reading any of this — the simulator handles it. This reference exists so the model isn't a black box: if the simulator says your database p99 is going to spike at ρ = 0.92, the math here tells you why.

Tail latency isn't predictable from average load. A server that's 50% utilised on average doesn't spend half its time idle and half its time at exactly 1 in-flight request — real arrivals and service times vary, requests cluster, and the queue's mean length grows nonlinearly as utilisation rises. Queueing theory is the closed-form math of how those queues behave.

Erlang derived the first such formula in 1909 for the Copenhagen telephone exchange: how many trunk lines did a switchboard need so that fewer than one call in a hundred got a busy signal? The answer wasn't “average concurrent calls + a safety factor” — it was an explicit function of arrival rate and service time. A century later, the math is unchanged; the systems are just bigger.

In this reference

1. Part 01Kendall notationA/S/c/K/N/D — the standard taxonomy for queueing systems.
2. Part 02Little's Law & stabilityL = λ · W, the ρ < 1 stability condition, and why 95% utilisation isn't 5% headroom.
3. Part 03M/M/1 and M/M/cSingle- and multi-server queues, Erlang C, and the square-root staffing rule.
4. Part 04M/G/1 — Pollaczek–KhinchineWhy service-time variance dominates tail latency, with a worked example.
5. Part 05M/M/c/K bounded queuesRate-limited endpoints, fixed-size pools, and blocking probability.
6. Part 06Jackson networksComposing M/M/c stations into networks, latency composition, what's not modelled.

Further reading

1. Harchol-Balter, M. Performance Modeling and Design of Computer Systems: Queueing Theory in Action. Cambridge University Press, 2013.
2. Erlang, A. K. “The Theory of Probabilities and Telephone Conversations.” Nyt Tidsskrift for Matematik B, 1909.
3. Kingman, J. F. C. “The single server queue in heavy traffic.” Mathematical Proceedings of the Cambridge Philosophical Society, 1961.
4. Kleppmann, M. Designing Data-Intensive Applications. O'Reilly, 2017.