The Two Generals’ Problem: Why Distributed Systems Can Never Achieve Absolute Certainty
When software engineers first dive into distributed systems, they eventually hit a psychological wall. We build pipelines, implement acknowledgments, add retries, and set up heartbeats, hoping to achieve a state where two independent nodes are entirely certain that a transaction has succeeded.
Then, we learn about the Two Generals’ Problem.
Long before the famous FLP impossibility result proved that asynchronous consensus is impossible in the presence of even a single unannounced failure, the Two Generals’ Problem laid bare the fundamental flaw of network communication. It explains why, no matter how much traffic or how many acknowledgments you send, two sides of a network can never be 100% certain that a message arrived.
The Parable of the Divided Army
To understand the core issue, imagine two divisions of an army camped on opposite sides of a hostile valley. Each division is led by a separate general. They want to coordinate a joint attack on the city below.
If they attack together, they will win. If only one general attacks, that division will be completely wiped out.
The catch? The only way for the generals to communicate is by sending messengers across the valley through enemy territory. There is a very real chance that a messenger will be captured, meaning the message never reaches the other side.
The Infinite Loop of Doubt
Let’s trace how communication unfolds:
- General A sends a messenger to General B: “Let us attack at dawn tomorrow.”
- General B receives the message. But General B knows that General A doesn’t know the message arrived. If General B attacks alone, they are doomed. So, General B sends an acknowledgment back: “Message received. I will attack at dawn.”
- General A receives the acknowledgment. But wait! General A now realizes that General B doesn’t know their acknowledgment got through. If General A’s acknowledgment is lost, General B will call off the attack out of caution. So, General A sends a reply to the acknowledgment: “Acknowledged your acknowledgment.”
This creates an infinite regression. No matter how many back-and-forth messages the generals exchange, the final message in the sequence always carries uncertainty because the sender of that final message can never be sure it was delivered.
Translating the Parable to Modern Networks
While the parable features medieval armies and captured messengers, the exact same mathematical reality governs modern cloud architecture, microservices, and databases.
When your API client sends a payment request to a Stripe or PayPal backend over the internet, you are General A, and the payment gateway is General B.
As illustrated above, no matter how many network packets you throw at the problem, the mathematical probability of achieving absolute, undeniable mutual certainty over an unreliable channel remains zero.
Two Generals’ Problem vs. FLP Impossibility
Engineers frequently confuse the Two Generals’ Problem with the FLP Impossibility theorem (Fisher, Lynch, and Paterson). While both deal with limits in distributed systems, they target entirely different layers of the problem:
| Feature | Two Generals’ Problem | FLP Impossibility Result |
| Core Focus | Communication over an unreliable, lossy channel. | Consensus in an asynchronous network with crash failures. |
| Primary Constraint | Messages can be dropped, delayed, or lost entirely. | Timing and clock drift; no upper bound on message delay. |
| System Model | Two nodes trying to agree on a single action. | Three or more nodes trying to reach distributed consensus. |
| The Result | Mutual certainty is mathematically impossible. | Deterministic consensus is impossible if even one node can fail silently. |
In short, the Two Generals’ Problem is about delivery and acknowledgment, whereas FLP is about agreement and timing.
How We Build Systems Anyway
If absolute certainty is impossible, how do modern distributed systems function without crashing society?
We stop chasing 100% certainty and instead design for eventual consistency, idempotency, and fault tolerance:
- Idempotent Operations: Design APIs so that if a message is retried due to a dropped acknowledgment, processing it twice produces the exact same result as processing it once (e.g., charging a credit card with a unique transaction ID).
- Timeouts and Circuit Breakers: Accept that networks fail. Set strict thresholds on how long a service will wait for an acknowledgment before failing gracefully.
- Compensating Transactions: Use patterns like Sagas to undo partial actions if a distributed workflow encounters a communication failure midway through.
What We Have Learned
In this article, we explored the Two Generals’ Problem, the foundational networking puzzle that proves absolute mutual certainty is mathematically impossible over an unreliable channel. We looked at why infinite message exchanges cannot eliminate doubt, clarified how it differs from the FLP impossibility theorem, and examined practical strategies like idempotency that allow us to build resilient systems in an uncertain world.
