Build fluency in the vocabulary of preventing a duplicate side effect from a redelivered message.
0 / 5 completed
1 / 5
At standup, a dev mentions a processing guarantee that ensures a message is handled effectively once, avoiding both a lost message and a duplicate side effect from a redelivery. What is this guarantee called?
Exactly-once semantics is a processing guarantee ensuring a message is handled effectively once, avoiding both a lost message and a duplicate side effect from a redelivery. At-least-once delivery on its own guarantees a message won't be lost, but allows a duplicate delivery that could trigger a duplicate side effect if not handled carefully. This stronger guarantee is what prevents a scenario like a payment being charged twice due to message redelivery.
2 / 5
During a design review, the team wants the consumer to attach a unique deduplication identifier to each message's processing, so a redelivered copy can be recognized and skipped rather than processed again. Which capability supports this?
An idempotency key, or deduplication identifier, lets a consumer recognize a redelivered copy of a message it already processed and skip reprocessing it, rather than triggering the side effect a second time. Processing every redelivered message again in full risks exactly the duplicate side effect exactly-once semantics is meant to prevent. This key is the concrete mechanism that achieves an exactly-once effect on top of an underlying at-least-once delivery guarantee.
3 / 5
In a code review, a dev notices the team distinguishes between guaranteeing a message is delivered exactly once at the transport level, which is extremely difficult, and achieving an exactly-once processing effect through idempotent handling of an at-least-once delivery. What does this represent?
Distinguishing exactly-once delivery from an exactly-once processing effect recognizes that guaranteeing true single delivery at the transport level is extremely difficult across an unreliable network, while achieving the equivalent effect through idempotent processing of an at-least-once delivery is far more practical. Treating the two as identical ignores that most real systems achieve the practical effect, not the literal transport guarantee. This distinction is central to understanding how exactly-once semantics is actually implemented in a real distributed system.
4 / 5
An incident report shows a payment was charged twice because a message was redelivered after a timeout, and the consumer had no idempotency key to detect it had already processed that same message. What practice would prevent this?
Attaching an idempotency key to the message lets the consumer recognize a redelivered copy and skip reprocessing it, preventing exactly the double charge this incident describes. Processing every redelivered message again in full leaves that duplicate side-effect risk wide open. This key is a standard, necessary safeguard anywhere a redelivery is possible and a duplicate side effect, like a duplicate charge, would be a real problem.
5 / 5
During a PR review, a teammate asks why the team builds exactly-once semantics through idempotent processing of an at-least-once delivery instead of relying on the transport layer alone to guarantee a true single delivery. What is the reasoning?
True end-to-end exactly-once delivery is extremely difficult to guarantee across an unreliable network, where a message can be delayed, retried, or redelivered for many legitimate reasons. An idempotency key achieves the same practical effect on top of a simpler, more achievable at-least-once delivery guarantee. The tradeoff is the added application-level work of generating, storing, and checking a deduplication identifier for every message processed.