Your best marketing campaign can become your worst outage.

The campaign works. People arrive. They click.

Their requests reach a part of the system that is already busy.

Watch what happens next. Each dot is one request. One worker handles them in order, with 10 milliseconds of work per request on average.

Build the queue, then lower the traffic

Turn up the arrivals and let a line build.

New requests wait for a turn. More arrive before the waiting work clears. The queue grows.

A request can spend more time waiting for the work to start than the work takes to finish. That waiting can turn into timeouts and customers giving up.

Then turn them down again.

The requests already waiting still need to be served. Traffic can return to normal before the waiting does.

When the worker has spare time, it can clear a burst. Close to its limit, there is less room to catch up before more work arrives.

Pause to inspect the queue, or advance one event at a time. The waiting count shows requests that have yet to start. The last completed request’s wait tells you how long that particular request queued.

The animation starts empty and keeps pending work when you change the rate. Restart clears it. Playback is slowed 40× so you can follow the requests. Random arrivals and processing times make each short run uneven.

After watching, open Why the wait grows below the animation. The curve describes long-run averages at a fixed arrival rate. A short simulated history, especially after changing the rate, can look very different.

This example models a queue. It does not simulate customer abandonment, timeouts or a real outage.

Ten quick jobs, one longer wait

Here is a separate example with fixed durations: ten requests arrive together, one worker handles them in order, each needs exactly 10 ms, and there is no other overhead.

The first finishes after 10 ms.

The tenth spends 90 ms waiting, then 10 ms processing. It finishes 100 ms after arriving.

Separate fixed-duration illustration: all ten requests arrive at 0 ms.
Separate fixed-duration illustration: all ten requests arrive at 0 ms.

Measure the wait as well as the work

Requests can wait for a worker thread, a database connection or another limited resource.

A timer that starts when processing begins misses that earlier wait.

Record arrival, access to the resource, and completion for the same attempt. Compare the wait for that resource with the remaining time until completion. That remaining time may include other waits too.

‣
Model details