Questions: Message Passing IPC: Semantics and Guarantees

Question 1

A payment service uses a message queue. Occasionally a network failure causes the same payment message to be delivered and processed twice, charging a customer's card two times. Which delivery semantic does this queue implement, and what is the recommended mitigation?

• A. Exactly-once delivery; the fix is to use a more reliable network connection
• B. At-most-once delivery; the fix is to add retransmission until an acknowledgment is received
• C. At-least-once delivery; the fix is to make payment processing idempotent — assign each message a unique ID and ignore duplicate deliveries
• D. FIFO ordering violation; the fix is to add sequence numbers to messages

Answer: (C)

At-least-once delivery guarantees the message arrives but may deliver it multiple times (the sender retransmits when it doesn't receive an ack, even if the ack was lost after successful processing). The standard mitigation is idempotent handlers: assign each payment a unique transaction ID, and reject or ignore any message with an ID that has already been processed. This effectively achieves safe behavior equivalent to exactly-once without the implementation cost. Option B describes at-most-once (fire-and-forget), which would lose payments rather than duplicate them.

Question 2

A developer chooses a blocking send over a non-blocking send in a producer-consumer pipeline. What is the key tradeoff?

• A. Blocking send is faster because it bypasses the message queue buffer entirely
• B. Blocking send synchronizes producer and consumer at the communication point, preventing the producer from outrunning the receiver, but the producer must wait idle until the receiver is ready
• C. Blocking send automatically guarantees exactly-once delivery, while non-blocking send does not
• D. Blocking send requires FIFO ordering while non-blocking send allows priority-based message reordering

Answer: (B)

A blocking (synchronous) send means the sender waits until the receiver picks up the message — they rendezvous at the communication point. This provides natural flow control (the producer cannot generate more messages than the consumer can handle) but wastes sender CPU time waiting. A non-blocking (asynchronous) send deposits the message in a buffer and returns immediately, freeing the sender to continue. Options C and D are false — blocking behavior and delivery reliability are independent design axes.

Question 3

Two message-passing systems can have identical send/receive API calls yet differ completely in their delivery reliability guarantees.

• T. True
• F. False

Answer: True

Delivery semantics (at-most-once, at-least-once, exactly-once) are implementation choices inside the communication layer, not reflected in the API surface. Two systems might both expose send(msg) and receive() calls while one silently drops messages on failure (at-most-once) and the other retransmits until acknowledged (at-least-once). Application code looks the same; the behavior under failure is radically different. This is why understanding the semantic contract of a message queue is essential before relying on it.

Question 4

At-least-once delivery is typically safer than at-most-once delivery because very likely delivery prevents data loss.

• T. True
• F. False

Answer: False

At-least-once delivery can cause duplicate processing, which for non-idempotent operations is as harmful as data loss. Charging a credit card twice is a serious error; so is inserting a database record twice. Whether 'safer' depends entirely on the application: at-most-once is safer when duplicates are catastrophic and occasional loss is tolerable; at-least-once is safer when loss is catastrophic and the application can be made idempotent. Neither is universally safer — the choice must match the operation's properties.

Question 5

Why is exactly-once delivery expensive to implement compared to at-least-once, and what application-level technique substitutes for it?

Model answer: At-least-once just retransmits until it receives an acknowledgment — simple. Exactly-once requires the system to also guarantee that if an acknowledgment was lost (so the sender retransmits), the receiver detects and discards the duplicate rather than processing it twice. This requires persistent deduplication state (sequence numbers, processed-message logs), coordinated bookkeeping on both sender and receiver sides, and recovery logic. The application-level substitute is idempotent message handlers: design operations so that processing the same message N times produces the same result as processing it once (e.g., 'set balance to X' rather than 'add X to balance'). Combined with at-least-once delivery, idempotent handlers achieve safe exactly-once semantics without the coordination overhead.

The key insight is that 'exactly-once' is a guarantee that must be maintained across failures, including failures that happen after processing but before the ack is sent. This failure window is what makes it hard. Idempotent handlers sidestep the problem entirely: if duplicates are harmless, there's no need to prevent them, and the guarantee you actually need (each message has the correct effect once) is achieved with much simpler infrastructure.