Exactly-Once Semantics
Also known as: exactly once delivery, EOS
Exactly-once semantics means each message produces its effect precisely once. Exactly-once *delivery* over an unreliable network is impossible; what systems like Kafka provide is exactly-once *processing* within a transactional boundary they control — at-least-once delivery plus deduplication and atomic offset commits.
Last reviewed · Part of the Architecture Glossary
In practice
The distinction that matters in a design review is delivery versus effect.
- Delivery cannot be exactly-once. The sender never learns whether a lost acknowledgement means the message arrived or did not, so it must choose between resending (at-least-once) and not resending (at-most-once).
- Effect can be exactly-once, if every consumer of the message is idempotent or the write and the offset commit are atomic.
Kafka's read_committed transactions give you the second within Kafka: a producer writes output records and consumer offsets in one transaction, so a reprocessed batch overwrites rather than appends. The guarantee ends the moment you write to something Kafka does not control — a Postgres row, an S3 object, a payment gateway.
When it matters
Mostly as a scoping question. "We need exactly-once" almost always means "duplicates cause a visible business error." That is solved with a dedupe key, not with a broker feature.
Common mistake
Buying a platform on the exactly-once bullet and then calling Stripe from the consumer. The transaction boundary stops at the external call; the idempotency key is still yours to implement.
See also
- At-Least-Once DeliveryAt-least-once delivery guarantees a message reaches its consumer one or more times, never zero.
- IdempotencyIdempotency is the property that performing an operation once and performing it many times produce the same end state.
- Transactional OutboxThe transactional outbox pattern writes an outgoing message into an `outbox` table inside the same database transaction as the state change it describes.