What it's for
- Some work is slow — resizing a video, building a report, sending ten thousand emails. A queue takes it out of the request: the web server writes a job, answers immediately, and a worker does the slow part whenever it gets there.
- It also decouples the two sides: producers and workers scale, deploy and fail independently, and a burst becomes a backlog instead of an outage.
Good to know
This toy models a work queue with at-least-once delivery and explicit acknowledgment, the RabbitMQ / SQS family — not every broker works this way. The states matter: a job is enqueued (the broker accepts it durably, and only then does the producer return), ready, delivered and in-flight while a worker processes it, and gone only when the worker acknowledges. While in-flight it's invisible to other workers for a timeout; if the ack never comes, it becomes ready again. That's the failure superpower — and the duplicate trap: a worker that does the work but dies before the ack causes redelivery, so the effect can happen twice. The answer is idempotency — the job carries an id, the worker checks before acting — not a promise of exactly-once from the queue itself. A queue is a buffer, not a speed boost: it decouples timing, but if jobs arrive faster than they're done, depth grows until capacity or retention runs out, and then something has to say no — here, a polite "try later". Ordering is scoped: this single queue with one worker finishes in order, but real brokers guarantee order only per partition or group, and retries and priorities can change completion order. Retries need bounds — attempts, backoff, and a dead-letter queue for poison messages; the DLQ quarantines, it doesn't fix. And this is a work queue: each job goes to exactly one worker. Publish-subscribe, where every subscriber gets a copy, is a different model with a different chapter's worth of trade-offs.
How it works, step by step
Why the steps go in this order
- The slow request comes first: the waiting user is the problem everything else fixes.
- The fast answer before the slow work: enqueue-and-return is the whole point, so it lands before the worker does anything.
- The ack is taught before the crash, because the crash only makes sense once "gone only when acknowledged" is established.
- The burst shows what the buffer buys; the overload step prices it, so the queue never reads as magic.
- The duplicate comes last: it's the subtle cost, and it only exists because the redelivery that saves jobs also replays them.
Before you rely on it
This is a toy: one queue, ten slots, twenty hand-set jobs, one worker at a hand-set pace — "drained in twelve seconds" is this toy's arithmetic, not a property of queues. Real brokers differ in ack protocols, persistence, retention and redelivery; a timeout expiring is not proof a worker stopped, which is exactly why duplicates happen. Nothing here makes slow work fast — the report still takes its seconds; the user just stops waiting for them. The cited sources describe real broker semantics and their own measured behavior.