In this lesson, you will learn why the central "referee" in a distributed transaction can become a single point of failure that leaves your data in limbo.
The Coordinator’s Burden
In the Two-Phase Commit (2PC) protocol, we rely on a Coordinator to manage the agreement process between multiple database nodes. The Coordinator asks every node if they are ready to commit (Phase 1) and then sends the command to actually finalize the transaction (Phase 2).
The problem arises if the Coordinator crashes exactly after it receives "Ready" votes but before it broadcasts the final "Commit" or "Abort" decision.
The Hanging Transaction
Imagine a system where a bank node has locked a customer's account balance because it voted "Yes" to a transaction. It is now waiting for the Coordinator to say "Commit." If the Coordinator crashes, that bank node is stuck in a state of uncertainty:
-- The node is in a 'Prepared' state
-- It cannot release the lock because it doesn't know if the others committed
-- It cannot unilaterally abort because the Coordinator might have told others to commit
SELECT transaction_id, status FROM pending_transactions WHERE state = 'PREPARED';
Because the Coordinator is offline, the participating nodes have no way of knowing the outcome. They must keep their resources—such as row locks—held indefinitely to maintain Transactional Integrity. If those locks aren't released, other incoming queries might queue up behind the blocked transaction, leading to a system-wide "hang."
Why This Is Risky
If the Coordinator’s recovery process takes too long or if its internal log is corrupted, the participants are effectively paralyzed. They cannot guess the outcome, as guessing wrong would violate the ACID property of Atomicity (where all nodes must act as one).
This is the classic trade-off in distributed systems: by requiring a central authority to ensure all nodes agree, we create a scenario where the entire system’s availability depends entirely on the uptime of that single Coordinator.
Key Takeaway: The Coordinator Failure Problem occurs when a central manager crashes after the "prepare" phase, forcing participants to hold locks indefinitely in a state of uncertainty, which can cause system-wide blocking and availability issues.