A payment service receives a 'charge $100' message via a queue with at-least-once delivery. The charge is processed successfully, but the acknowledgment is lost in the network. What happens next, and what is the consequence?
AThe sender marks the transaction failed and requires the user to retry manually
BThe message is redelivered and, without deduplication logic, the customer is charged again
CThe queue detects the duplicate and automatically cancels the second charge before it is processed
DThe sender waits indefinitely for an acknowledgment without ever retransmitting
At-least-once semantics guarantee delivery by retransmitting until an acknowledgment is received. Since the sender cannot distinguish 'message lost' from 'acknowledgment lost,' it retransmits the original message. If the payment handler simply processes every message it receives, the customer gets charged twice. At-least-once queues (RabbitMQ, SQS) provide no automatic deduplication — that is the application's responsibility. This is why idempotency or explicit deduplication logic is essential for financial and state-mutating operations over at-least-once transports.
Question 2 Multiple Choice
Which property of an operation makes it safe to use with at-least-once delivery without explicit deduplication logic?
ACommutativity — the operation can be applied in any order without changing the result
BIdempotency — applying the operation multiple times produces the same result as applying it once
CAtomicity — the operation completes fully or not at all
DDeterminism — the operation always produces the same output for the same input
Idempotency is the key property: f(f(x)) = f(x). Setting a field to a specific value ('status = PAID') is idempotent — doing it twice leaves the record in the same state as doing it once. Incrementing a counter is not idempotent — doing it twice adds twice. Commutativity is a different property (about ordering, not repetition) and does not help with duplicates. Atomicity prevents partial execution but doesn't prevent re-execution. Determinism alone doesn't help — a deterministic non-idempotent operation executed twice still causes double application.
Question 3 True / False
At-least-once delivery is strictly stronger than exactly-once delivery because it guarantees nearly every message arrives, while exactly-once mainly guarantees messages are not duplicated.
TTrue
FFalse
Answer: False
This reverses the strength ordering. Exactly-once is strictly stronger: it guarantees both that every message arrives (no loss) AND that it arrives exactly once (no duplicates). At-least-once only guarantees no loss — it explicitly allows duplicates. A system with exactly-once guarantees satisfies all the requirements of at-least-once, but not vice versa. The confusion likely comes from reading 'at least one' as 'at minimum one, therefore guaranteed.' The 'at least' means the count is ≥ 1, which includes 1, 2, 3, ... — duplicates are the cost, not a feature.
Question 4 True / False
The fundamental reason at-least-once delivery can produce duplicate messages is that a sender cannot determine whether a missing acknowledgment means the message was lost or the acknowledgment was lost.
TTrue
FFalse
Answer: True
This is the core insight. From the sender's perspective, a timeout after sending is ambiguous: (1) the message was lost and the receiver never saw it, or (2) the message arrived, was processed, and the acknowledgment was lost. In case 1, retransmitting is correct; in case 2, retransmitting causes a duplicate. Since the sender cannot distinguish the two cases, the safe choice (at-least-once) is to retransmit in both cases. Exactly-once delivery requires additional coordination (idempotency tokens, transactional guarantees) to resolve this ambiguity at the receiver side.
Question 5 Short Answer
Explain why idempotency at the application layer is often preferred over exactly-once delivery at the transport layer as a solution to the duplicate message problem.
Think about your answer, then reveal below.
Model answer: Exactly-once delivery requires coordination between sender and receiver — typically a two-phase commit or a distributed transaction — which adds latency, complexity, and failure modes. Achieving exactly-once at the transport layer requires the infrastructure to maintain state about which messages have been delivered, which can be expensive and may fail under partitions. Idempotency, by contrast, moves the burden to the application layer: if the handler is designed so that processing a message twice has the same effect as processing it once, duplicate delivery becomes harmless without any coordination overhead. Most real systems (Kafka, SQS) default to at-least-once delivery and expect consumers to either be idempotent or implement deduplication via message IDs — a pattern that scales better than distributed transaction coordination.
The tradeoff is: exactly-once is simpler to reason about but expensive to implement correctly at infrastructure level. Idempotency requires careful application design but composes better with the realities of distributed networks, where exactly-once guarantees often break down under failure scenarios anyway.