Distributed Transactions - Commits

distributedsystem y3s1/lecturenotes/ds systemdesign

🌟 Distributed Transaction
🌟 ACID - Isolation
[!video]- 20. Handle Distributed Transactions | Two-Phase Commit (2PC), Three-Phase Commit (3PC), SAGA Pattern

Distributed Commit is a process in distributes system that ensure a group of nodes (or databases) agree to perform a transaction(saving data) in a consistent way; either all commit or all abort even in the presence of failures.

Analogy

Imagine a group of friends deciding whether to go on a trip. Everyone must agree. If even one person says “no”, the trip is canceled for everyone.

Similarly, in a distributed transaction:

• All nodes must agree to commit the transaction.
• If any node fails or votes to abort, the whole transaction is rolled back.

Commit Protocols

One Phase Commit

Simplest commit protocol.
The (elected) coordinator sends a commit command directly to all participants.

1. Coordinator sends COMMIT to all Participants.
2. Participants execute and return success/failure.

No Pre-Checks - If one participant fails during commit, no way to rollback consistently.
Therefore one phase commit used for a single node or low risk of failure systems.

Two Phase Commit

Two Phase Commit (Blocking Commit Protocol)

Three Phase Commit

Three-phase commit (3PC) is an extension of the two-phase commit where the commit phase is split into two phases. This helps with the blocking problem that occurs in the two-phase commit protocol.

• If coordinator crashes, participants have enough information to safely decide on commit or abort.
• Non-blocking.

Prepare (Pre Vote) Phase

• Coordinator sends: “Can you commit?”
• Participants respond with Yes or No.

Pre-Commit Phase

• If all say Yes, coordinator sends: PRE-COMMIT (write to log, but don’t execute).
• Participants acknowledge READY.

The pre-commit phase accomplishes the following:

• If the participant nodes are found in this phase, that means that every participant has completed the first phase. The completion of prepare phase is guaranteed.
• Every phase can now time out and avoid indefinite waits.

Commit Phase

Once all participants are READY, coordinator sends COMMIT.

Important

3PC is better than 2PC, but it’s not applied often in practice coz it’s complex and the conditions under which 2PC blocks rarely occurs.

How 3PC fix 2PC Blocking Problem

In 2PC, if the coordinator crashes after the participants have voted “Yes” but before sending the commit decision, participants are stuck waiting indefinitely, unsure whether to commit or abort

3PC assumes:

• No network partition (i.e., synchronous network model).
• Failures are detectable (e.g., via timeout).

In 3PC Prepare phase all participant say “Yes”, coordinator sends a “pre-commit” message. Participants acknowledge and enter a prepared-to-commit state. now all participants know coordinator decide to commit (or Abort).

Now Coordinator Crash…

• Participants know that all voted “Yes” and entered the ready-to-commit state.
• They can coordinate among themselves to reach a consensus (using timeout or election).
• Since all have acknowledged the Pre-Commit, they can safely commit after a timeout, avoiding indefinite blocking.

Recovery Coordination Among Participants

Participants use timeouts and a simple consensus mechanism (sometimes called “participant election”):

Step-by-step:

1. Timeout Expiration:
   • Each participant starts a timer after entering the Pre-Commit state.
   • If the final Commit message doesn’t arrive before the timeout, they suspect the coordinator has failed.
2. Coordinator Election (Optional):
   • One participant (e.g., with the highest ID) can declare itself as a temporary coordinator.
   • It asks others about their current state.
   • If all others reply that they’re in Pre-Commit, the temporary coordinator decides to send a Commit.
3. Decision Propagation:
   • The new coordinator broadcasts the Commit decision to all participants.
   • Everyone commits locally and acknowledges.
4. If any participant is in an earlier state (e.g., only voted Yes):
   • Then the new coordinator cannot safely commit, because there’s no agreement.
   • In that case, it must abort the transaction.

Saga Pattern

The Saga Pattern

Summary

Pattern	Best For	Blocking	Strong Consistency	Notes
2PC	Traditional DBs	Yes	Yes	Simple, but blocks on failure
3PC	Critical systems needing non-blocking	No	Yes	Safer than 2PC, but heavier
Saga	Microservices	No	Eventual	Requires compensation logic
Transactional Outbox	Event-driven systems	No	Yes (per service)	Ensures DB + event in same transaction
Eventual Consistency	Loose coupling, async processing	No	Eventually	Needs observability & retries
Raft/Paxos	DB internals, coordination services	No	Yes	For low-level consensus, not business logic