What a Serving System Must Guarantee
The vocabulary the rest of this field is written in — offered load, utilisation, throughput, concurrency and latency percentiles — defined precisely enough to compute with.
The four quantities
For a system in steady state over a long interval:
- Offered load — the rate at which requests arrive, in requests per second. It is a property of the world, not of your system.
- Service time — the time one request occupies a server, excluding any time spent waiting. It is a random variable; write for its mean.
- Throughput — the rate at which requests complete.
- Concurrency — the number of requests inside the system at a given instant, waiting or being served.
- Latency — the time from arrival to completion, including queueing: always.
- Capacity — the maximum completion rate. With identical servers each able to complete requests per second, .
- Utilisation — the fraction of capacity the offered load asks for.
Stability
Let be the number of arrivals and the number of departures by time , with and departure capacity . If then the backlog satisfies . Consequently throughput is achievable only when , and, as the next page shows, only keeps latency finite.
Assumptions
- Arrivals and departures are counted over a common interval and no requests are dropped or abandoned. Dropping requests is precisely how a real system escapes this proposition — it converts an unbounded queue into a visible error rate, which is the point of admission control.
- Capacity is constant. Autoscaling makes a function of time and is treated separately.
What this does not say
This says nothing about what happens at slightly below one. It is tempting to read "stable for " as "fine for ", and that reading is wrong: the queue is finite at but its mean length is around a hundred requests. Stability is a statement about , not about whether your latency target is met.
Which latency you mean
A latency distribution is summarised by its quantiles. Write for the CDF of and
for the -quantile — "p99" is , the value 99% of requests come in under.
Let have mean . Then for every ,
and the bound is attained: for every there is a distribution with mean whose -quantile exceeds . In particular a mean of 200 ms permits a p99 of just under 20 s, and permits nothing worse.
Key idea
A factor of is all the mean ever tells you. At that factor is 100. So "average latency 200 ms" is consistent with a p99 anywhere from 200 ms to 20 s, and the two situations are completely different products. This is the precise reason serving systems are specified by quantiles rather than means.
Composing stages
Real requests pass through several stages in sequence: a load balancer, a tokeniser, a retrieval call, the model itself. It is tempting to budget a latency target by adding up per-stage p99s.
Let with the non-negative. Then
Independence is not needed; the bound holds for arbitrarily dependent stages.
Key idea
To hit an end-to-end p99 across stages, the union bound says it is enough for each stage to hit its quantile. With stages that is each stage's p99.75, not its p99. Budgeting with per-stage p99s is not conservative — it is optimistic, and the error grows with the number of stages.
What an SLO actually asserts
A service-level objective is a triple: a metric, a quantile, and a window. "p99 latency under 500 ms over a rolling 28 days" asserts that, of the requests in any such window, at most 1% took longer than 500 ms.
Three consequences follow immediately from the definitions and are worth stating because they are routinely missed.
- An SLO is a budget, not a bound. 1% of a billion requests is ten million slow requests. The SLO permits them.
- The window matters as much as the quantile. A 28-day p99 permits a single catastrophic hour, because one hour is 0.15% of 28 days. A one-hour p99 does not.
- Quantiles of quantiles are not quantiles. Averaging per-minute p99s over a day does not give the day's p99, and in general underestimates it, because the average of a set of quantiles is not the quantile of the pooled distribution.
Where this goes
The next pages turn these definitions into predictions. Little's Law and the Capacity of a Serving System pins down the relationship between concurrency, throughput and latency with no distributional assumptions at all. Queueing and the Utilisation Wall explains why latency explodes well before , and Tail Latency and Fan-Out Amplification explains why the explosion is felt first, and worst, by requests that touch many machines.
References
- PaperJ. Dean, L. A. Barroso (2013). The Tail at ScaleThe paper that made tail latency a first-class concern in system design.
- PaperJ. D. C. Little (1961). A Proof for the Queuing Formula L = λWReferenced here for the definitions of L, λ and W used throughout.
These works are cited as sources to read, not reproduced. All exposition, examples and problems on this site are written independently; where an argument is standard, the citation points to a canonical treatment.
Results stated on this page
- PropositionStability requires utilisation below oneproof includedA queue with arrival rate above service capacity has a backlog growing without bound, so throughput equals offered load only when utilisation is strictly below 1.
- PropositionThe mean constrains the tail only by a factor of 1/(1-p)proof includedThe p-quantile of a non-negative latency is at most its mean divided by 1-p, and that bound is attained, so a mean of 200 ms permits a p99 of 20 s and nothing sharper can be said.
- PropositionPercentiles do not addproof includedThe 99th percentile of a sum of independent stages is generally far below the sum of their 99th percentiles, and never above it by more than the stage count allows.
- DefinitionOffered load, throughput, concurrency, utilisationThe six quantities every capacity argument is written in, and the distinction between throughput and capacity.
- DefinitionService-level objectiveA metric, a quantile and a window — and the three consequences that follow from reading it literally.