Practice this topic in a realistic system design interview
When a system sends a message, several things can go wrong.
The producer may retry because it did not hear back. The broker may send the same message again because a consumer crashed. The consumer may finish the work but crash before telling the broker it is done.
Delivery semantics are the rules for what a messaging system does when delivery fails, succeeds, or is uncertain.
These rules matter because they shape the consumer code. If a message can arrive twice, the consumer must handle duplicates. If a message can be lost, the business must be okay with that loss.
The most important practical lesson is this:
Delivery semantics describe message delivery. Your application still owns the business result.
This chapter covers at-most-once, at-least-once, and exactly-once delivery in practical terms.
Before comparing the delivery types, 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, "I am done with this message." |
| Commit | The system records progress, such as deleting the message or saving the consumer's position. |
A broker can know whether a message was acknowledged. It usually cannot know whether the 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 sends the message again. The second attempt may charge the card again unless the consumer is designed to prevent that.
That is why delivery rules and duplicate-safe consumer code go together.
The usual three delivery types 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 a limit | Duplicate delivery | Consumer must handle duplicates safely |
| Exactly-once | Avoid duplicate effects within a clear boundary | More moving parts | Transactions or duplicate checks |
These rules do not work automatically. They depend on broker settings, safe storage, retries, acknowledgments, and how the consumer writes its results.