Delivery Semantics
Last Updated: May 27, 2026
When a system sends a message, several things can go wrong.
The producer may retry because it did not receive an acknowledgment. The broker may redeliver a message because a consumer crashed. The consumer may finish the work but fail before committing progress.
Delivery semantics describe what the messaging system promises about message delivery and redelivery.
These promises matter because they shape the consumer code. If a message can be delivered twice, the consumer must handle duplicates. If a message can be lost, the business must be able to tolerate loss.
The most important practical lesson is this:
Delivery semantics describe message delivery. Your application still owns the correctness of the business effect.
Delivery vs Processing
Before comparing the semantics, separate two ideas:
| Concept | Meaning |
|---|---|
| Delivery | The broker gives a message to a consumer. |
| Processing | The consumer performs the business action. |
| Acknowledgment | The consumer tells the broker it is done. |
| Commit | The system records progress, such as deleting the message or storing a consumer offset. |
A broker can know whether a message was acknowledged. It usually cannot know whether the consumer's business action was completed correctly.
For example, a payment worker might charge a card and then crash before acknowledging the message. The broker sees no acknowledgment, so it redelivers. The second delivery may charge the card again unless the consumer is designed to prevent that.
That is why delivery semantics and idempotency belong together.
The Three Semantics
The usual three categories are:
| Semantic | Broker Behavior | Main Risk | Consumer Requirement |
|---|---|---|---|
| At-most-once | Try once, then move on | Message loss | Application must tolerate loss |
| At-least-once | Retry until success or policy limit | Duplicate delivery | Consumer must be idempotent |
| Exactly-once | Avoid duplicate effects within a defined boundary | Hidden complexity | Transactional or deduplicated processing |
These are not absolute guarantees by themselves. They depend on configuration, durability, retention, acknowledgments, retries, and how the consumer writes its results.