We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
2 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Distributed Systems Core
Free preview: the first 2 parts of this 10-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Distributed Systems Core
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Think of a traditional wedding ceremony. The officiant asks one person: "Do you take this person to be your spouse?" They say "I do." Then the officiant asks the other person the same question. They say "I do." Only then does the officiant say "I now pronounce you married." Both parties committed, but neither was married until the coordinator (the officiant) made the final declaration.
Two-phase commit (2PC) follows this exact pattern. A coordinator asks all participants "Can you commit?" (Phase 1. Prepare). Each participant responds yes or no. If everyone says yes, the coordinator tells them all to commit (Phase 2. Commit). If anyone says no, everyone aborts.
2PC was formalized by Jim Gray in 1978 and has been the standard distributed transaction protocol for decades. Every XA-compliant database supports it. It's used in traditional banking systems, enterprise middleware, and anywhere distributed atomicity is non-negotiable.
But 2PC has a fatal flaw that has been known since day one: if the coordinator crashes after sending some commit messages but before sending all of them, the remaining participants are stuck. They've voted "yes" (locked their resources), but they don't know whether to commit or abort. They can't ask the coordinator, it's dead. They can't ask other participants, those might be in the same boat. They just... Wait. This blocking problem is why many modern systems avoid 2PC entirely.
Phase 1. Prepare (Voting Phase):
Phase 2. Commit (Decision Phase):
| Phase | Coordinator | Participants | Locks Held? |
|---|---|---|---|
| Start | Sends PREPARE | . | No |
| After PREPARE | Waiting for votes | Write to WAL, acquire locks, vote YES/NO | Yes |
| After all YES | Sends COMMIT | . | Yes |
| After COMMIT received | Done | Commit, release locks | Released |
| After any NO | Sends ABORT | . | Yes |
| After ABORT received | Done | Rollback, release locks | Released |
The critical vulnerability: Between receiving all YES votes and sending COMMIT, the coordinator holds the fate of the entire transaction. If it crashes in this window: