Practice the vocabulary of coordinating an all-or-nothing transaction across multiple independent databases.
0 / 5 completed
1 / 5
At standup, a dev mentions a coordinator asking every participating database whether it can commit a transaction, and only telling them to actually commit once every single one has agreed. What is this protocol called?
Two-phase commit, or 2PC, has a coordinator ask every participating database whether it can commit a transaction in a prepare phase, and only tells them to actually commit in a second phase once every single one has agreed. Each database committing independently with no coordinated agreement risks one succeeding while another fails, leaving the transaction only partially applied. This two-phase structure is what gives 2PC its all-or-nothing guarantee across multiple independent databases.
2 / 5
During a design review, the team wants every participant to durably record its prepare-phase vote to disk before replying, so it can recover its correct state even if it crashes right after voting. Which capability supports this?
Durable vote logging at each participant, writing its prepare-phase vote to disk before replying, lets it recover its correct state even if it crashes right after voting, rather than forgetting whether it had already agreed to commit. Replying with no durable record risks a participant losing track of its own vote after a crash, which can leave the transaction's outcome ambiguous. This durability is what lets 2PC recover cleanly from a participant failure partway through the protocol.
3 / 5
In a code review, a dev notices that once every participant has voted to commit, the coordinator itself becomes a single point of blocking, since a participant that has already voted must wait indefinitely for the coordinator's final decision if it goes silent. What does this represent?
The coordinator-blocking problem is inherent to two-phase commit, since a participant that has already voted to commit must hold its locks and wait indefinitely for the coordinator's final decision if the coordinator goes silent. A participant proceeding independently as soon as it votes would abandon the whole point of waiting for unanimous agreement first. This blocking risk is one of 2PC's best-known drawbacks and a key reason some systems favor an alternative like the saga pattern instead.
4 / 5
An incident report shows a transaction's locks were held for hours across several databases because the coordinator crashed right after the prepare phase, leaving every participant stuck waiting indefinitely for a commit-or-abort decision that never arrived. What practice would prevent this?
Running the coordinator with its own durable, recoverable state and a timeout-and-recovery mechanism lets a crashed coordinator's decision eventually be resolved, rather than leaving every participant blocked forever. Running with no durable state or recovery risks exactly the hours-long lock-holding this incident describes. This durability and recovery capability is what makes 2PC operationally viable despite its known blocking risk.
5 / 5
During a PR review, a teammate asks why the team uses two-phase commit for a multi-database transaction instead of just committing each database's portion independently and hoping they all succeed. What is the reasoning?
Committing each database independently risks one succeeding while another fails, leaving the transaction only partially applied across the participating databases. 2PC only commits once every participant has unanimously agreed in the prepare phase, avoiding that partial-application risk. The tradeoff is the added latency and the coordinator-blocking risk inherent to holding locks open across two full round trips before the transaction actually completes.