A service sends a payment instruction and the acknowledgement is lost. State what the two generals result says about resolving this with additional messages, give the design a payment service uses instead, and name the one failure that design cannot remove.

A service sends a payment instruction and the acknowledgement is lost. State what the two generals result says about resolving this with additional messages, give the design a payment service uses instead, and name the one failure that design cannot remove.

Approach: Show that any protocol with a finite number of messages has a last message that can be lost, then move the guarantee from the delivery of the message to the effect it produces.

No finite protocol resolves it, so a payment service builds at least once delivery plus an idempotent effect keyed on a client supplied identifier, which makes the effect exactly once while delivery stays at least once, and the failure it cannot remove is the expiry of the deduplication key. The two generals argument is an induction on the final message: take any protocol whose two sides end in agreement and consider its last message. That message can be lost and its sender cannot learn whether it arrived, so the receiver's state must be identical whether or not it was sent, which means the protocol also works without it. Repeat until no messages remain, so agreement was never conditional on the exchange. A sender that cannot distinguish a lost request from a lost acknowledgement must therefore retry. The design that follows is a deduplication key: the client generates an idempotency key, the service records the key with the outcome inside the same transaction that moves the money, and a retry carrying the same key returns the stored outcome without moving money again. The residual risk is retention, since once the key expires a very late retry is indistinguishable from a new instruction, and any effect outside that transaction needs its own key.

Follow-up: How long should the key store retain a key when the client is a mobile application that can retry days later?

Key concepts: two generals, at least once delivery, idempotent effect, deduplication key.