Learn the vocabulary of a messaging guarantee that tolerates an occasional duplicate redelivery.
0 / 5 completed
1 / 5
At standup, a dev mentions a messaging guarantee where a consumer might occasionally receive the same message more than once after a crash and redelivery, rather than a guarantee that a message is processed exactly one time no matter what. What is this guarantee called?
At-least-once delivery is a messaging guarantee where a consumer might occasionally receive the same message more than once, typically because the system redelivers a message it isn't sure was fully processed after a crash or a dropped acknowledgment. Exactly-once semantics is the contrasting, and much harder to achieve, guarantee that a message is processed exactly one time no matter what. This tolerance for an occasional duplicate is the tradeoff at-least-once delivery accepts in exchange for a much simpler underlying implementation than true exactly-once semantics.
2 / 5
During a design review, the team wants the consumer to safely handle a redelivered duplicate message under at-least-once delivery by applying an idempotency key so the same message never causes a duplicate side effect. Which capability supports this?
An idempotency key lets the consumer detect and skip a message it has already fully processed, by checking that key against a record of what's already been handled, so a redelivered duplicate under at-least-once delivery doesn't cause a second, unwanted side effect. Processing every redelivered message identically with no idempotency key risks applying the same effect, like a charge or an email, more than once. This idempotency handling is what lets an application built on top of at-least-once delivery behave, in effect, as if it had exactly-once semantics.
3 / 5
In a code review, a dev notices a consumer acknowledges a message to the broker only after it has fully finished processing that message, rather than acknowledging it immediately upon receipt. What does this represent?
This is ack-after-processing, which accepts the possibility of a duplicate redelivery, since a crash between finishing the work and sending the acknowledgment means the broker will redeliver the message, in exchange for never silently losing a message the way acknowledging immediately upon receipt would risk. Exactly-once semantics is a stronger guarantee that ack-after-processing alone doesn't provide on its own, since it only avoids message loss, not duplication. This ack-after-processing timing is the standard way at-least-once delivery actually achieves its 'at least' guarantee rather than an 'at most' one.
4 / 5
An incident report shows a customer was charged twice for the same order, because a payment-processing consumer crashed and was redelivered the same message under at-least-once delivery, and reprocessed the charge with no idempotency check in place. What practice would prevent this?
Applying an idempotency key to the payment operation lets the system detect that a redelivered message has already been applied and skip reprocessing it, closing exactly the gap that caused the double charge in this incident. Continuing to process every redelivered message as if it were guaranteed new is exactly what let the duplicate charge occur after the consumer's crash and redelivery. This idempotency handling is a mandatory practice for any consumer built on top of at-least-once delivery whose side effects, like a payment charge, can't safely be applied more than once.
5 / 5
During a PR review, a teammate asks why the team designs consumers to be idempotent under at-least-once delivery instead of investing in a messaging system that guarantees true exactly-once semantics end to end. What is the reasoning?
True exactly-once semantics end to end is far more complex and costly to guarantee across an entire distributed pipeline, since it typically requires coordinating transactions across the messaging system, the consumer, and any downstream side effect. At-least-once delivery paired with an idempotent consumer achieves the same practical outcome, no double-processing, with a much simpler underlying messaging system that only needs to guarantee delivery, not exactly-once semantics itself. The tradeoff is the responsibility for correctness shifting onto the consumer's own idempotency logic instead of the messaging infrastructure guaranteeing it automatically.