Delivery Semantics
Last Updated: January 9, 2026
When you send a message through a messaging system, what guarantees do you have about its delivery? Will it definitely arrive? Could it arrive more than once?
These questions are at the heart of delivery semantics. Delivery semantics define the contract between a messaging system and its users about how many times a message will be delivered.
Understanding these guarantees is essential because choosing the wrong semantics can lead to lost data, duplicate processing, or systems that are unnecessarily complex.
In this chapter, you will learn:
- The three delivery semantics: at-most-once, at-least-once, and exactly-once
- How each semantic works and its trade-offs
- Why exactly-once is harder than it sounds
- How to achieve effective exactly-once processing
- How to design systems that handle each semantic correctly
The Three Delivery Semantics
Messaging systems offer three levels of delivery guarantees. Each makes different trade-offs between reliability, performance, and complexity.
| Semantic | Guarantee | Message Loss | Duplicates |
|---|---|---|---|
| At-most-once | Delivered 0 or 1 times | Possible | Never |
| At-least-once | Delivered 1 or more times | Never | Possible |
| Exactly-once | Delivered exactly 1 time | Never | Never |
Let us explore each in detail.
At-Most-Once Delivery
At-most-once means a message is delivered zero or one times. The system makes one attempt and does not retry if it fails. This is the simplest semantic but accepts that messages may be lost.
How It Works
The broker delivers the message and immediately deletes it, regardless of whether the consumer received or processed it.
Implementation
At-most-once is the simplest to implement:
Key characteristics:
- No acknowledgment waiting
- No retry logic
- Minimal overhead
- Fast performance
When to Use
At-most-once is appropriate when:
- Loss is acceptable: Metrics, logs, or telemetry where missing some data points is fine
- Speed matters more than reliability: Real-time gaming, live video streaming
- Data is ephemeral: Sensor readings that will be replaced by the next reading anyway
- Duplicates are worse than loss: Some financial scenarios where double-processing is catastrophic
Advantages and Disadvantages
Advantages
- Simplest implementation
- Lowest latency
- No duplicates
- Minimal resource usage
Disadvantages
- Messages may be lost
- No delivery guarantee
- Cannot retry failures
- Not suitable for critical data
At-Least-Once Delivery
At-least-once means a message is delivered one or more times. The system keeps retrying until it receives confirmation of delivery. This ensures no messages are lost but accepts that messages may be delivered multiple times.
How It Works
The broker retries until it receives acknowledgment. If the acknowledgment is lost, the broker retries, causing duplicate delivery.
Why Duplicates Happen
Even in a perfectly implemented system, duplicates can occur because the broker cannot distinguish between:
- Consumer never received the message
- Consumer received but did not process
- Consumer processed but crashed before ACK
- Consumer ACKed but ACK was lost
The Broker's Dilemma
When to Use
At-least-once is appropriate when:
- Loss is unacceptable: Financial transactions, orders, critical notifications
- You can handle duplicates: Through idempotency or deduplication
- Processing is idempotent: Setting a value, upserting a record
- Reliability trumps performance: Most business-critical operations
The Idempotency Requirement
At-least-once delivery requires idempotent consumers. An operation is idempotent if performing it multiple times has the same effect as performing it once.
Achieving Idempotency
Strategy 1: Natural Idempotency
Design operations that are naturally idempotent:
Strategy 2: Deduplication with Message IDs
Track processed message IDs:
Strategy 3: Database Constraints
Use unique constraints to prevent duplicates:
Exactly-Once Delivery
Exactly-once means a message is delivered exactly one time. No loss, no duplicates. This is the holy grail of messaging semantics but is harder to achieve than it sounds.
Why Exactly-Once Is Hard
The fundamental problem is the Two Generals' Problem. Two parties communicating over an unreliable channel cannot reach certainty about shared state.
The fundamental problem: there is always a moment where the sender has committed but does not know if the receiver has received. The network can fail at any point.
What "Exactly-Once" Actually Means
When systems claim "exactly-once," they typically mean one of two things:
1. Exactly-once delivery (rare):
The infrastructure guarantees each message is delivered exactly once. This requires tight coupling between sender, broker, and receiver.
2. Exactly-once processing (more common):
Messages may be delivered multiple times, but the effect is as if it were processed once. This is achieved through idempotency and deduplication.
How Kafka Achieves Exactly-Once
Kafka achieves exactly-once semantics within its ecosystem through:
1. Idempotent Producer
Producers assign sequence numbers. Broker deduplicates:
2. Transactions
Atomic writes across multiple partitions:
3. Consumer Offsets in Transaction
Consumer offset commits are part of the transaction:
When to Use
Exactly-once is worth the complexity when:
- Duplicates are catastrophic: Financial ledgers, inventory counts
- You control the entire pipeline: All components support transactions
- The performance cost is acceptable: Transactions add latency
- Correctness is non-negotiable: Regulatory requirements
Summary
Delivery semantics define the guarantee about how many times a message will be delivered:
At-Most-Once:
- Delivered 0 or 1 times
- May lose messages, never duplicates
- Simplest, fastest
- Use for: metrics, logs, real-time streams
At-Least-Once:
- Delivered 1 or more times
- Never loses messages, may duplicate
- Most common choice
- Requires idempotent consumers
- Use for: most applications
Exactly-Once:
- Delivered exactly 1 time
- No loss, no duplicates
- Hardest to achieve
- Use for: financial transactions, critical operations
Key insight: True exactly-once delivery is impossible over unreliable networks. What we achieve is exactly-once processing through idempotent consumers. At-least-once delivery combined with idempotent consumers gives you effective exactly-once processing with less complexity than native exactly-once support.
But what happens when a message fails processing repeatedly? It cannot stay in the queue forever, blocking other messages. This is where dead letter queues come in. In the next chapter, we will explore how to handle failed messages gracefully.