A Message Queue Is a Contract About Delivery, and the Contract Has Terms
Key takeaway: A message queue is a contract about how messages are delivered, and the contract has terms — at-least-once, at-most-once, ordering, and retry behaviour — and the terms determine what the consumer must handle, so the consumer must be designed for the queue’s delivery guarantees.
The Queue as a Delivery Contract
A message queue decouples a producer from a consumer — the producer sends a message, and the consumer processes it later, asynchronously. The queue promises to deliver the message, but the promise has terms, and the terms vary depending on the queue and its configuration.
The most important term is the delivery guarantee — whether a message is delivered at least once, at most once, or exactly once. This determines what the consumer has to handle, and it is the foundation of the contract between the queue and the consumer.
The Delivery Guarantees
| Guarantee | What it means | What the consumer must handle |
|---|---|---|
| At-least-once | A message may be delivered more than once | Duplicate processing |
| At-most-once | A message may be lost | Missing messages |
| Exactly-once | A message is delivered exactly once | Nothing, but hard to achieve |
At-least-once delivery means a message may be delivered and processed more than once, so the consumer must be able to handle duplicates — typically by making the processing idempotent, so that processing the same message twice has the same effect as processing it once. At-most-once delivery means a message may be lost, so the consumer must be able to handle missing messages.
The Ordering Question
Another term of the contract is ordering — whether messages are delivered in the order they were sent. Some queues preserve ordering, and some do not, and the ordering guarantee determines whether the consumer can rely on messages arriving in a particular order.
For applications where order matters — where processing a later message before an earlier one would be wrong — the consumer must either use a queue that preserves ordering or handle out-of-order messages, and the design must account for the queue’s actual ordering behaviour.
The Retry and Failure Behaviour
The contract also includes how failures are handled — what happens when a consumer fails to process a message. The queue may retry the message, move it to a dead-letter queue after repeated failures, or drop it, and the consumer must be designed for the queue’s retry and failure behaviour, handling messages that are retried and messages that end up in a dead-letter queue.
The Bottom Line
Design the consumer for the queue’s delivery contract, since a message queue promises delivery with terms — at-least-once, at-most-once, ordering, and retry behaviour — and the terms determine what the consumer must handle. Make processing idempotent for at-least-once delivery, handle missing messages for at-most-once, account for the queue’s ordering behaviour, and design for the queue’s retry and failure handling, since the consumer must be built for the queue’s actual guarantees, not an assumed ideal.
