Skip to content
Devgo

Exactly-once delivery

A delivery guarantee that each message is processed once, no more, no less, despite failures and retries. True exactly-once is expensive; most systems achieve it via at-least-once + idempotent consumers + transactions, not magic.

When to use
  • Payments and any effect that must not duplicate.
  • Within a single stream processor.
When not to
  • When at-least-once + idempotent consumer suffices (most cases).
  • Across systems where you can't coordinate.

Definition

Exactly-once means the effect of processing a message happens exactly once even if the message is delivered multiple times. It's typically implemented as at-least-once delivery plus idempotent processing and/or transactional consume+produce ( transactions).

Why it exists

At-least-once causes duplicates (double charges); at-most-once causes loss. Some domains (payments) need exactly-once effects. The honest way is , not a magic transport.

How it works

Make consumers idempotent (dedup by id) so redelivery is a no-op, OR use transactional consume-transform-produce ( streams) so input offset and output are committed atomically. Either way, the effect is once.

Scaling limits

needs a dedup store. Transactions reduce throughput and add latency. End-to-end exactly-once across heterogeneous systems is very hard; it usually holds only within one system.

Cost shape

Dedup store or transaction overhead. Blow-ups: large dedup tables and transaction contention.

Alternatives

  • At-least-once + idempotency — Simpler and usually equivalent in effect.
  • At-most-once — No duplicates but possible loss.

Failure modes

  • Assuming the transport guarantees it end-to-end when it doesn't.
  • Dedup store as a bottleneck.
  • Transaction contention.

, , ,