the Two Generals problem
termprogrammingcloudnetworking
The proof that two parties on an unreliable channel can never be certain they agree to act together.
Two generals must attack simultaneously and can communicate only by messengers who may be captured; whichever confirmation is sent last, its sender cannot know it arrived, so no finite protocol reaches certain agreement, a result formalized in the 1970s. It is the bedrock impossibility beneath distributed transactions, exactly-once delivery, and every retry loop with idempotency keys. Its harder sibling, the Byzantine generals, adds traitors; real systems settle for probably-agreed, which is what timeouts and acknowledgments actually buy.
Two armies must attack simultaneously to win and can communicate only by messengers who may be captured. The first general sends a time, and cannot know it arrived. The second acknowledges, and cannot know the acknowledgement arrived. No finite sequence of messages produces certainty on both sides, and the problem is provably unsolvable.
It is not a puzzle, it is a boundary condition on distributed systems, and it means that guaranteed agreement over an unreliable channel is impossible rather than merely difficult. Every real system therefore works around it rather than solving it, and knowing that changes what you look for in a design.
The practical consequences are everywhere. Exactly-once delivery does not exist; what exists is at-least-once delivery plus idempotent processing, which produces the same observable result and is a genuinely different mechanism. A payment system cannot be certain a charge succeeded, so it reconciles. TCP does not guarantee the peer received your last message, only that it acknowledged earlier ones. Any design that assumes certainty about a remote party's state is assuming something the mathematics says it cannot have.