Two-Phase Commit (2PC): All or Nothing, Together
Two-Phase Commit (2PC) ensures a distributed transaction is atomic: all participants either commit or abort together. A coordinator first asks all nodes to prepare (vote), then issues a final commit or abort.
Why it exists
When an operation involves multiple independent systems, like transferring money between two different banks, you need a way to ensure it either completes everywhere or fails everywhere. Without a protocol, a failure halfway through could leave the system in an inconsistent state—money debited from one account but never credited to the other. 2PC was designed to solve this by providing atomic transactions in a distributed environment.
The mental model
Think of 2PC as a wedding ceremony with a coordinator (the officiant) and participants (the partners). The coordinator doesn't just declare the union; it first asks each partner to confirm their readiness ('I do'). This is the Prepare Phase. Only after receiving confirmation from everyone does the coordinator make the final, binding pronouncement ('I now pronounce you...'). This is the Commit Phase. If either partner says 'no' or the coordinator faints before the final pronouncement, the wedding is off (aborted).
How it works
The protocol operates in two distinct phases. First is the Prepare Phase: the coordinator sends a 'prepare' message to all participating nodes. Each participant checks if it can execute the transaction, writes its decision to a durable log for recovery, and votes 'yes' or 'no' back to the coordinator. Second is the Commit Phase: if the coordinator receives 'yes' from all participants, it logs the decision and broadcasts a 'commit' message. If it receives even one 'no' or a participant times out, it broadcasts an 'abort' message. Participants then use this final message to make the transaction permanent or roll it back.
When to use it
Use 2PC when you need absolute, ironclad atomicity for an operation that spans multiple resources, such as different databases or microservices. It's common in financial systems or critical inventory management where strong consistency is a non-negotiable business requirement.
When not to use it
Avoid 2PC in systems where high availability and performance are more important than strong consistency. The protocol is 'blocking'—if the coordinator fails, all participants must wait, holding database locks and other resources until it recovers. This can cause cascading failures. For many modern applications, especially in microservices, patterns like the Saga pattern are preferred for their better fault tolerance.
One canonical example
A classic example is a distributed database transaction. Imagine updating a customer record and their order record, where each record lives on a separate database server. A transaction coordinator initiates 2PC. It asks the customer DB server to prepare the update and the order DB server to prepare its update. If both servers respond 'yes', the coordinator sends 'commit' to both. If the order DB server failed and responded 'no', the coordinator would tell the customer DB server to 'abort', ensuring the system remains consistent.
Interview question
What is the primary reason Two-Phase Commit (2PC) is often avoided in systems prioritizing high availability and performance?
- a.Its blocking mechanism can lead to resource contention and system unavailability.Correct
- b.It adds significant overhead, making simple transactions overly complex.
- c.It only guarantees eventual consistency, which is insufficient for critical operations.
- d.It requires all participating systems to use identical transaction managers.
Why? this is the answer
The card states that 2PC is avoided in systems prioritizing high availability and performance because its 'blocking' nature can cause participants to wait indefinitely if the coordinator fails, holding resources and leading to cascading failures and reduced availability. While it can add complexity, the core issue highlighted is its impact on availability due to blocking.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on distributed systems — each one lists the topics its interview covers.
See open roles