Exactly-once in practice
A food delivery app runs a campaign: ₹50 cashback on your first order. A month later finance notices that about 3% of customers received ₹100. Every team swears its service is idempotent, and every team is right. The app retried a payment with no key, so some customers had two orders. The cashback consumer deduplicated perfectly, by event id, and two orders have two event ids.
Exactly-once is not a feature you switch on in one place. It is a property of the whole path, and it fails at the weakest hop.
An order passes through an app, an API, a database, Kafka and a consumer that credits cashback. List every place a duplicate or a loss can be introduced. Which single guard would you add first?
What exactly-once actually means#
The delivery guarantees article makes the core argument: a message cannot be delivered exactly once over a network that loses acknowledgements, because a sender that hears nothing cannot tell "not done" from "done, reply lost". What you can have is an exactly-once effect: deliver at least once, and make every repeat do nothing.
exactly-once effect = at-least-once delivery + idempotent processing, at every hop
The last three words are the part that gets dropped. A system has as many hops as it has network calls, and each one can repeat or lose work in its own way.