Two-Phase Commit (2PC)

Цели урока

• Understand the atomicity problem in distributed transactions
• Know the two phases of 2PC and the roles of coordinator and participants
• Explain the blocking problem and why the coordinator is a SPOF
• Distinguish when to use 2PC vs Saga vs Outbox pattern

Предварительные знания

• Understanding of ACID transactions and WAL (write-ahead log)
• Familiarity with distributed systems failure modes (crash, omission, timing)
• Basic understanding of the CAP theorem

Bank transfer between two banks: money debited, network drops, credit never happens. Without 2PC this is not a bug - it is an architectural guarantee of data loss.

• **Google Spanner** - 2PC + Paxos: the only database with global strong consistency for cross-shard transactions
• **Kafka Transactions (2017)** - exactly-once semantics via a variant of 2PC with a replicated TransactionCoordinator
• **PostgreSQL XA** - PREPARE TRANSACTION since 2005, used in enterprise distributed transactions
• **Amazon DynamoDB Transactions (2018)** - 2PC under the hood for multi-item ACID transactions
• **Stripe** - idempotency keys as a defense against partial execution without full 2PC overhead

Jim Gray and the birth of distributed transactions

Jim Gray published the description of Two-Phase Commit in 1978 as part of the work on System R at IBM. In 1998 he received the Turing Award - the highest honor in computer science - for his work on transaction management and databases. In 2007 Gray disappeared at sea during a solo sailing trip. The Jim Gray eScience Award for data researchers was named in his honor.

The Atomicity Problem in Distributed Systems

**2007. TJX Companies - the largest payment data breach in history at the time. 94 million cards compromised. One of the technical roots: inconsistency between systems during transaction processing.** This is the atomicity problem: money debited from account A, but due to a network failure never credited to account B. The money vanished between systems.

**Atomicity** - a transaction property where the operation either completes fully or not at all. On a single machine, the DBMS guarantees this via WAL. But when data lives on two different servers - who guarantees "all or nothing"?

Classic example: a bank transfer between two banks, each with its own database. Three failure scenarios: 1. money debited, network dies before credit - sender loses funds 2. credit fails, but debit already committed - same result 3. credit succeeds but debit never runs - money created from nothing. All three are catastrophic.

The problem extends beyond banking. Any distributed operation: writing to a DB and publishing an event to Kafka, updating multiple shards, synchronizing between microservices. All require a coordinator that either confirms all changes or rolls back all of them.

Two-Phase Commit: the two phases

**2PC was invented by Jim Gray in 1978 - the same person who received the Turing Award in 1998 for his work on transactions and databases.** The idea is elegant: split the commit into two steps - first ask everyone whether they are ready, and only if all say yes - commit. Any refusal at any step triggers a rollback for everyone. This solves the atomicity problem across nodes.

Phase 1: Prepare (voting)

The coordinator broadcasts PREPARE to all participants. Each participant: verifies it can execute the operation; writes its intention to WAL (write-ahead log); acquires the necessary locks. Then replies YES or NO. If even one replies NO - the coordinator immediately broadcasts ABORT to all, including those who said YES.

Phase 2: Commit or Abort

If all replied YES - the coordinator writes the COMMIT decision to its own WAL, then broadcasts COMMIT to all participants. Each participant commits its changes and releases locks. Key point: once the coordinator has written the decision to its log, the transaction is considered committed regardless of whether the messages reached participants.

**Participant state machine:** INIT -> WORKING (received PREPARE) -> PREPARED (replied YES, waiting for decision) -> COMMITTED or ABORTED. The PREPARED state is critical: the participant has already acquired locks and cannot make a decision on its own. It is blocked until it receives a response from the coordinator.

2PC problems: blocking and SPOF

**2PC is a blocking protocol.** This is its primary vulnerability. Between the two phases, participants hold locks and cannot make a decision independently. If the coordinator crashes during this window, the result is a deadlock of indefinite duration.

The blocking scenario: t1 - coordinator sends PREPARE to all. t2 - all reply YES. t3 - coordinator writes COMMIT to WAL. t4 - coordinator crashes before broadcasting COMMIT. Result: participants are blocked in PREPARED indefinitely. They hold locks on data, do not know whether to commit or abort, and cannot make a decision without the coordinator.

**WAL for recovery:** coordinator and participants write every step to the log before executing. On recovery: if no PREPARED in log - can abort; if PREPARED exists without COMMITTED - ask coordinator; if COMMITTED exists - apply changes. WAL makes the protocol recoverable, but does not eliminate blocking.

**Coordinator as SPOF:** standard 2PC has a single point of failure - the coordinator. Solution: replicate the coordinator via Paxos or Raft. This is how Google Spanner works: 2PC for atomicity + Paxos for coordinator fault tolerance.

Alternatives and real-world use of 2PC

**2PC is used where strict atomicity is genuinely required and blocking is acceptable.** PostgreSQL has supported PREPARE TRANSACTION for the XA protocol since 2005. Google Spanner combines 2PC with Paxos: 2PC provides atomicity across shards, Paxos replicates the coordinator for fault tolerance. Kafka Transactions (since version 0.11) use a variant of 2PC for exactly-once semantics.

When 2PC is not the right choice

Microservices are the classic case where 2PC fits poorly. Problems: tight coupling (all services must support the protocol), blocking (one slow service blocks everyone), the coordinator becomes a bottleneck at scale. For microservices, the Saga pattern is a better fit - a chain of local transactions with compensating actions on failure. See the distributed transactions lesson.

**Outbox pattern** - a practical alternative to 2PC for microservices: writing to DB and publishing a Kafka event atomically via a single outbox table in the same DB. A separate process reads the outbox and publishes events. Provides at-least-once delivery without a distributed transaction.

Вопросы для размышления

• Google Spanner uses 2PC + Paxos: 2PC for atomicity across shards, Paxos for coordinator replication. What specific problem of 2PC does Paxos solve, and why can Paxos alone not replace 2PC?

Связанные уроки

• dist-07-transactions — 2PC implements atomic commit for distributed transactions
• ds-03-consensus — 2PC is a restricted form of consensus
• dist-08-paxos — Paxos generalises 2PC to tolerate coordinator failure
• dist-12-consistency — 2PC provides atomic durability underpinning strong consistency
• db-03-acid