Two Generals Problem

A classical computer-science result: two parties cannot reach guaranteed agreement over an unreliable channel. The proof is short and brutal, and it’s the reason “exactly-once delivery” over a network is impossible in general.

The setup

Two generals must coordinate an attack. They’re on opposite hills. The only way to communicate is messengers who run through the enemy valley between them — any messenger may be captured.

General A sends a messenger: “attack at dawn.” For A to be sure B got it, A needs an acknowledgment. B sends “got it, attacking at dawn” — but for B to be sure A got the ACK, B needs an ACK-of-ACK. And so on, forever. No finite exchange of messengers ever achieves common knowledge.

The networking equivalent

A producer sends a message to a broker. The broker receives it and sends back an ACK. The ACK vanishes on the wire. The producer must now pick:

• Retry → possibly cause a duplicate.
• Give up → possibly lose the message.

The network does not tell the producer which situation it is in. Ever. Adding more ACKs adds more possible loss points — it doesn’t eliminate the ambiguity.

Why it matters

This is the bedrock reason that:

• Exactly-once delivery is not a feature any vendor can ship. See delivery-guarantees.
• At-least-once + idempotency|idempotent processing is the practical answer. Duplicates are physical reality; idempotency makes the effect once.
• Network partitions are unavoidable. Pairs with cap-theorem|CAP and pacelc|PACELC.

The result generalizes: any protocol that depends on guaranteed mutual agreement over an unreliable channel is reaching for something that doesn’t exist. Consensus protocols (Paxos, Raft) work around this by accepting partial failure and converging eventually, not by solving the Two Generals Problem.

See also

• delivery-guarantees — the messaging-broker manifestation
• idempotency — the workaround
• cap-theorem — the broader distributed-systems framing