A payment service sends a 'charge $50' message to a billing system. The billing system processes the charge and sends an acknowledgment, but the acknowledgment is lost in the network. The payment service retries. Under at-least-once semantics, what happens next?
AThe billing system detects the duplicate automatically via TCP checksums and discards the second message
BThe billing system receives the duplicate message and, without additional deduplication logic, charges the customer $100 total
CThe payment service detects the timeout and cancels both the original and retry charges
DAt-least-once semantics prevents retries; only at-most-once semantics would retry the message
Under at-least-once delivery, the sender retries until it gets an acknowledgment. The receiver has no obligation to detect duplicates — that's not part of at-least-once semantics. When the billing system receives the second 'charge $50' message, it has no way to know (without additional machinery) that it already processed this exact request, so it processes it again. This is the fundamental problem that exactly-once semantics (via deduplication) solves. The key insight is that the acknowledgment loss is the trigger: the sender *cannot know* whether the original was processed or not, so it must retry.
Question 2 Multiple Choice
A system is described as providing 'exactly-once semantics' for message processing. What is the core technical mechanism that makes this possible?
AThe network layer guarantees each packet is only ever transmitted once, so no duplicates reach the application
BThe sender assigns each message a unique ID; the receiver maintains a log of processed IDs and skips processing if the ID has been seen before
CThe sender and receiver use a two-phase commit protocol to agree on whether each message was processed
DMessages are buffered and batched, so duplicates within the same batch cancel each other out before processing
Exactly-once semantics cannot be achieved by preventing duplicate delivery — unreliable networks make that impossible. Instead, the receiver maintains a deduplication log: every message carries a unique identifier, and before processing, the receiver checks whether that ID has already been processed. If so, it skips processing and re-sends the original response. This means a message may be *delivered* more than once, but the *effect* occurs exactly once — hence the term 'effectively-once.' The deduplication check and the processing must be atomic to close any race condition window.
Question 3 True / False
Exactly-once semantics prevent a message from ever being physically delivered to the receiver more than once.
TTrue
FFalse
Answer: False
This is the most important misconception about exactly-once semantics. The name is somewhat misleading. Exactly-once semantics do not — and cannot — guarantee that the underlying network delivers a message only once. Networks will always have the possibility of retransmission. What exactly-once semantics guarantee is that the *processing effect* occurs exactly once: through deduplication, the receiver recognizes and discards redundant deliveries. Systems like Kafka even document this as 'effectively-once': duplicate delivery may occur, but duplicate processing is prevented.
Question 4 True / False
Exactly-once semantics are most important for operations with non-idempotent side effects, such as charging a payment or incrementing a counter, where processing the same message twice produces incorrect results.
TTrue
FFalse
Answer: True
This is precisely the right framing. For idempotent operations — reading a value, setting a field to a specific value, or any operation where 'do it twice' equals 'do it once' — at-least-once delivery is sufficient and much simpler. The overhead of exactly-once (deduplication state storage, atomic check-and-process, ID management) is only justified when duplicates cause real harm. Financial transactions are the canonical example: charging $50 twice causes a real $50 error. Counter increments are another: incrementing a view count twice gives wrong analytics. The design decision is always: is this operation idempotent, or does it require exactly-once protection?
Question 5 Short Answer
Exactly-once semantics are often described as 'effectively-once.' What does this mean, and what must a system do to achieve this guarantee?
Think about your answer, then reveal below.
Model answer: Effectively-once means a message may be physically delivered more than once, but its effect on the system state occurs exactly once. The system achieves this through deduplication: each message carries a unique identifier, and the receiver maintains a persistent log of all message IDs it has already processed. When a duplicate arrives, the receiver recognizes the ID, skips processing, and re-sends the original acknowledgment. The deduplication check and processing must be atomic to ensure no duplicate can slip through in a concurrent environment. The key insight is that the problem is not preventing duplicate *delivery* (impossible in unreliable networks) but ensuring duplicate *processing* has no additional effect.
The terminology matters because it clarifies where the guarantee lives: not in the transport layer (which may deliver duplicates) but in the application layer (which detects and ignores duplicate processing). This framing also explains the cost: the receiver must maintain deduplication state reliably, which means persistent storage, atomic operations, and eventual garbage collection of old IDs.