Delivery Semantics
Understand what at-most-once, at-least-once, and effectively-once processing really promise.
2–5 minute refresher
P0104105106107
P181828384
Consumer group A · offset 106Consumer group B · offset 82
Delivery promise + processing boundary + side-effect semantics
30second
refresher
refresher
Delivery semantics describe how message transfer and acknowledgement behave under failure. End-to-end outcomes also depend on consumer state, offset commits, retries, and every side effect beyond the broker.
What problem does it solve?
A consumer can crash before or after processing but before acknowledging. The broker must choose between possible loss and possible duplicate delivery.
How it works
- Assign a stable identity to each logical event.
- Fetch from a durable position or subscription.
- Apply the state transition idempotently or transactionally.
- Commit progress only after the durable outcome.
- Send external effects through their own deduplicated or outbox-driven path.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| At-most-once | No broker redelivery | Possible loss |
| At-least-once | Retry until acknowledged | Duplicate processing |
| Transactional processing | Atomic state and progress | Scoped systems and coordination |
What happens if?
The consumer writes state, then crashes before committing its offset
The message is delivered again. A stable event ID and atomic outcome record let the consumer recognize the duplicate and return success without applying the change twice.
Where it appears
- Kafka transactions
- SQS visibility timeout
- Pub/Sub acknowledgements
- Transactional outbox
Senior interview modeWhat does exactly-once mean in a real event pipeline?Show answer
Only within a clearly defined atomic boundary. The broker may atomically connect input offsets and output records, but databases, emails, payments, and other external effects still need idempotency or reconciliation.