Queues & Messages
From “it works” to “it behaves”
Section titled “From “it works” to “it behaves””In the first module you published a message and consumed it. That flow works — but it makes a lot of quiet decisions for you: the queue disappears on restart, the message lives only in memory, one consumer might hog everything, and messages pile up forever if nobody reads them.
This module is about the knobs. Each one is a small property on a queue or a message that changes what happens under load, on failure, and on restart.
What this module covers
Section titled “What this module covers”| Lesson | What you’ll learn |
|---|---|
| Queue properties | durable, exclusive, auto-delete, and x-* arguments |
| Message properties | Persistence, content type, headers, priority, and correlation |
| Acknowledgements | Manual vs auto ack, requeue, and at-least-once delivery |
| Prefetch & QoS | Fair dispatch, and why unbounded prefetch overloads one worker |
| TTL & limits | Message/queue expiry, max length, and overflow behaviour |
Two objects, two sets of knobs
Section titled “Two objects, two sets of knobs”Everything here lives on one of two things — the queue (declared once, shared by everyone) or the message (set fresh on every publish):
flowchart LR q["Queue properties (durable, exclusive, auto-delete, TTL, max-length)"] --> life["shape the queue's lifecycle & limits"] m["Message properties (persistent, priority, headers, content-type)"] --> deliv["shape one message's delivery & handling"]
Getting these right is most of what separates a demo from a system you’d trust in production. The single most important one — acknowledgements — is the mechanism behind “at-least-once” delivery, so give that lesson extra attention.