Lesson 02: 2PC

Two-Phase Commit

To solve the Bank Transfer problem, we introduce a third node: The Coordinator. The Coordinator manages the transaction across Server A and Server B using the Two-Phase Commit (2PC) protocol.

The transaction is split into two strict phases:

Two-Phase Commit Simulator

Watch a successful 2PC transaction. Then, try clicking on Node B to force it to vote "NO" (e.g. insufficient funds) and see how the Coordinator aborts the transaction cleanly without destroying money.

Coordinator Node
Idle
Node A (Debit)
๐Ÿ”“
Waiting...
Node B (Credit)
๐Ÿ”“
Will vote YES
(Click to toggle vote)
System is idle.

The Problem with 2PC

2PC guarantees strict ACID properties across a distributed network. It is mathematically elegant. And yet, almost no modern high-scale system (like Amazon or Netflix) uses it.

Why? It is a blocking protocol.

During Phase 1, Node A acquires a database lock on Alice's account. It must hold that lock until it receives the final decision in Phase 2. What if the Coordinator crashes right after Phase 1? Node A is stuck holding the lock forever. Alice's account is frozen, and nobody can read or write to it until the Coordinator is manually rebooted.

Furthermore, 2PC is slow. It requires multiple network round-trips for every transaction. At scale, this latency is unacceptable. Instead, modern microservices use an asynchronous approach called The Saga Pattern.

Check yourself

1. Why is Two-Phase Commit (2PC) considered an anti-pattern in modern high-scale architectures?

Because 2PC locks resources across the network until the Coordinator finishes the transaction, a Coordinator crash results in a catastrophic freeze of the database.