Every formula so far assumed a steady state. A spike above μ has none: it accumulates a backlog equal to the area of λ − μ over its duration, and that area drains afterwards at whatever headroom is left. A sixty-second spike can be a three-and-a-half-minute incident, and the worst lag arrives at the moment the spike ends.
Core ideas
Three quantities, each a division of the same area, and none of them is a steady state.
While λ > μ the amount waiting grows at λ − μ per second, so the total left at the end of the spike is that excess multiplied by how long it lasted. Two spikes with the same peak and different durations leave completely different backlogs, and the peak alone does not predict the incident.
Once the spike ends the consumer is still receiving λ_after, so only μ − λ_after per second is available to work through the backlog. Headroom, again: the same quantity the knee was a function of, doing the same job in a different form.
Consumer lag — how far behind the newest message the reader is, in time — is the backlog divided by μ. It rises throughout the spike, reaches its worst at the instant the arrival rate returns to normal, and only then starts to fall. Latency does not recover when the spike ends; it recovers when the area does.
The material
What accumulates, what drains it, how long that takes, and why the worst moment is after the surge is over.
A system drains at μ. The arrival rate is λ_before until the spike, λ_spike for d seconds, then λ_after. The excess is λ_spike − μ, the peak backlog is that excess times d when positive and zero otherwise, the headroom afterwards is μ − λ_after, and the drain time is the backlog divided by the headroom.
Two conditions are worth checking before any of it: the system must have been stable before the spike, or the backlog did not start at zero; and the headroom afterwards must be positive, or there is no drain time at all and the backlog is permanent.
A minute of overload, three and a half minutes of incident. The asymmetry is entirely in the two rates: work arrived 500 a second faster than it could be handled and leaves only 200 a second faster, so every second of the spike costs two and a half seconds of recovery.
That ratio is the useful generalisation: the recovery is excess ÷ headroom times the length of the spike. Systems run close to μ have very little headroom, so their recovery multiplier is large — another form of the knee, and another reason a target utilisation is chosen rather than a maximum one.
The backlog rises linearly to 30 000 at t = 60, then falls linearly to zero at t = 210, so at t = 30 it is 15 000 on the way up and at t = 135 it is 15 000 again on the way down. Lag follows the same shape divided by μ: nothing, then thirty seconds at the moment the surge ends, then a slow return. An alert on lag fires late in the spike and clears long after it, which is exactly what the arithmetic says should happen.
Keep everything the same but let the arrival rate return to 1000 rather than 800. The headroom is now zero, the drain time is undefined, and the 30 000 that accumulated is permanent: the system is stable in the sense that the backlog stops growing, and the lag stays at thirty seconds for ever. Recovery is not a property of a spike ending; it is a property of the headroom that follows it.
A surge to 900 a second against μ = 1000 builds nothing at all, however long it lasts. There is no excess, so there is no area. What that surge does do is raise ρ from 4/5 to 9/10, which the knee says multiplies the response time by two — a real effect, and a different one from a backlog.
The controls are the familiar ones, in a new arrangement. More headroom shortens the drain and every other quantity on this page. A bounded queue or a token bucket caps the area by refusing part of the spike, trading the backlog for loss. And smoothing the arrivals — the variability lesson's c_a² — reduces how much of a surge is a spike at all.
This is also the lesson that says when the rest of the course applies. Every steady-state formula here describes a system whose load has been constant long enough to settle; during a spike, none of them is true, and the honest calculation is the area. Afterwards they become true again, which is what the drain time is measuring — the time until the model's assumption is met.
Interactive
A spike is an area, and the drain is longer than the spike
Method
Everything is one area and two divisions, in this order.
λ_before < μ. If it was not, the backlog did not start at zero and the peak is larger than the area of the spike alone.
(λ_spike − μ) × d is the peak backlog, and it occurs at the end of the spike rather than at its start. A negative excess means no backlog at all.
μ − λ_after. If this is zero or negative, stop: there is no drain time, and the backlog is permanent until something else changes.
Backlog over headroom is the drain time; backlog over μ is the worst lag. The total episode is the spike plus the drain.
A retention window, an alerting threshold, a customer's patience. The answer that matters is rarely the peak backlog itself but the time the system spends away from normal.
A consumer that drains a thousand a second, a steady eight hundred, and one minute at fifteen hundred.
The two halves of the episode are not symmetric and nothing makes them so. The backlog is built at 500 a second and removed at 200, so it takes two and a half times as long to leave as it took to arrive.
Note where the worst lag sits: at t = 60, the instant the arrival rate returns to normal. A dashboard watched during the surge shows lag still climbing as the traffic falls, which is confusing only if the backlog is being thought of as a rate rather than as an area.
For a faded rehearsal, keep everything but let the spike last thirty seconds instead of sixty. The supplied first move is that the excess is unchanged at 500 a second, so the peak halves. Predict the drain time, the worst lag and the total episode before computing them.
You should be able to compute the peak backlog, the drain time, the worst lag and the total episode from a piecewise arrival rate, say when there is no drain time at all, and explain why the steady-state formulas of this course do not apply while it is happening.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.