Why a message queue?
A spiky producer, a slow consumer. Call it directly and the producer dies with it — buffer it in a queue and the spike becomes a backlog instead.
The idea in 21 seconds
A fixed animation — no controls, nothing to configure. It shows the shape of the problem and the shape of the fix, with the story written out underneath.
~21s animated walkthrough: a checkout API blocking on a slow receipt worker vs. the same work buffered in a queue.
Checkout works. You press pay, and before the response comes back the API has already rendered a receipt PDF and handed it to the mail server. Two seconds, maybe three on a bad day, and the customer sees a confirmation page with the receipt already on its way. Nobody designed it that way on purpose — rendering the PDF was five lines, and it was simply easier to do it right there in the request.
Then a sale starts. Ten checkouts a second against a worker that renders two. The eleventh request doesn't fail, which is the part that fools you — it waits. So does the twelfth. Each one is holding a request thread hostage while the mail server takes its time, and the pool is only eight threads deep. Within a few seconds every thread in the API is parked inside the receipt code, and the next customer to press pay doesn't get a slow checkout, they get a 503. The cart page is down. Nothing is broken, and everything is unavailable.
The cruelty is that the receipt was never urgent. Nobody refreshes their inbox during checkout. You coupled the thing that must answer in 200ms to the thing that takes two seconds, and the slow one won.
So the video flips it: a queue slides between them. Now the API writes a message and returns — three milliseconds, no matter what the mail server is doing — and the workers pull jobs when they're ready. The spike doesn't vanish. Watch the slots fill: ten deep, and the oldest receipt is now three seconds behind. But a backlog is a number on a dashboard you can add consumers to, where an exhausted thread pool was a checkout page that wouldn't load.
The point. A queue doesn't make the work faster — the same two jobs a second still trickle through. What it buys you is that the producer's latency stops depending on the consumer's throughput. You trade an instant, visible failure for a delay you have to monitor, which is why the queue depth graph is the first dashboard you build after adding one.
Interactive producer/consumer simulator
Now drive it yourself. Pick a mode, set the produce rate and consumer capacity, then run or spike the load and watch real counters — producer latency, queue depth, lag, 503s, timeouts — respond to your settings.
- Latency stops being shared. In sync mode the producer's latency is the consumer's latency. Queued, the write costs 3ms no matter how far behind the workers are — compare the two latency tiles above.
- The failure changes shape, not existence. Spike sync mode and you get 503s and timeouts on the checkout path. Spike queued mode and you get depth and lag — the same overload, moved somewhere you can watch it and add consumers.
- A queue is not more capacity. Keep the produce rate above consumer capacity and queued mode never recovers: depth climbs until it hits the cap and the producer gets back-pressured anyway. Buffers absorb bursts, not deficits.
- Lag is the new SLO. "Oldest message behind" is what your customer actually feels once the response no longer carries the work — which is why queue depth is the first dashboard you build after adding one.
Related guides & quizzes
The simulator builds the intuition. These go deeper on the tradeoffs, then check whether it stuck.