What Problem Are We Solving?
The network can fail after an operation succeeds but before acknowledgement. A broker can redeliver a message. A consumer can persist data and crash before committing its offset. From the outside it may be impossible to know immediately whether the action happened. Redelivery is therefore normal in many reliable systems, and “never repeat” can conflict with “never lose.”
How It Works
Exactly-once should be treated as a guarantee over a specific boundary, not a magical transport property. Some platforms provide transactional processing inside a controlled scope, but an external effect creates another boundary. In practice it is often cheaper to use at-least-once delivery and make the business operation idempotent or record a unique identifier for effects already applied.
What the Business Gets
The business gets a strong guarantee where duplication actually costs money, corrupts state, or creates an irreversible effect. Other flows can tolerate duplicate delivery without paying for global coordination, preserving throughput and simpler scaling.
What the Team Gets
Teams must define what “once” means: message delivery, state mutation, or the complete external business effect. Idempotency keys, inbox patterns, deduplication, and transactional logs become deliberate mechanisms instead of assumptions about the broker.
What the Customer Gets
Customers get the outcome that matters: retries and redelivery do not create a second irreversible action where duplication is unacceptable.
What We Pay For It
Strict exactly-once semantics require state, coordination, and integration constraints. The wider the guarantee boundary, the more expensive it becomes. There is also an organizational risk: promising exactly-once without defining “once” gives the business false confidence.
When Not to Add It
Do not buy strict guarantees for telemetry, notifications, or flows where duplicates can be tolerated or filtered. Strengthen the guarantee where duplication creates financial, legal, or operational damage.
What to Ask Before the Decision
- What exactly must happen once?
- Where does that guarantee end?
- Can the operation be made idempotent?
- What happens after a timeout when the result is unknown?
- How expensive is a duplicate compared with coordination?
In the End
Exactly-once is not a free queue setting. It is an expensive guarantee tied to a concrete business effect. The real goal is not “exactly once everywhere,” but no duplicate outcome where duplication truly matters.