2PC (Two-Phase Commit)

Overview

Two-Phase Commit (2PC) is a distributed protocol that guarantees atomicity across multiple database nodes. When a transaction touches data on more than one shard—for example, updating a user’s profile on shard A and their billing record on shard B—2PC ensures that either both updates commit or both roll back. There is no state where one shard has committed and another has not.

In AI infrastructure, 2PC matters whenever a single logical operation spans multiple storage systems. Consider a RAG pipeline that must atomically update a document in the vector store and its metadata in a relational database, or a multi-tenant system where embedding insertion and quota accounting must succeed or fail together. Without an atomic commit protocol, partial failures leave the system in inconsistent states that are difficult to detect and expensive to repair.

2PC was formalized by Jim Gray in 1978 and remains the foundation of distributed transaction protocols in systems like PostgreSQL (for distributed transactions via prepared transactions), Google Spanner, CockroachDB, and TiDB. Understanding its mechanics—and its limitations—is essential for designing reliable distributed AI infrastructure.

How It Works

The Participants

2PC involves two roles:

• Coordinator (Transaction Manager): The node that initiated the transaction. It orchestrates the protocol by sending messages to participants and making the final commit/abort decision.
• Participants (Resource Managers): The nodes holding data that the transaction modifies. Each participant independently decides whether it can commit, but the coordinator decides whether it will commit.

Phase 1: Prepare (Voting Phase)

The coordinator sends a PREPARE message to every participant involved in the transaction. Each participant then:

1. Executes the transaction locally up to the point of commit (but does not commit).
2. Writes all changes to its write-ahead log (WAL) so they survive crashes.
3. Acquires all necessary locks on the affected rows or resources.
4. Responds with either VOTE_COMMIT (yes, I can commit) or VOTE_ABORT (no, something went wrong).

// Phase 1: Coordinator sends PREPARE to all participants
for _, participant := range participants {
    response := participant.Prepare(txn)
    votes = append(votes, response)
}

// Coordinator collects votes
allYes := true
for _, vote := range votes {
    if vote != VOTE_COMMIT {
        allYes = false
        break
    }
}

At this point, each participant has made a durable promise: if it voted yes, it guarantees it can commit the transaction even if it crashes and restarts. The WAL entry ensures recovery is possible.

Phase 2: Commit or Abort (Decision Phase)

Based on the votes, the coordinator makes an irrevocable decision:

• If all participants voted COMMIT: the coordinator writes a COMMIT record to its own WAL, then sends COMMIT to every participant.
• If any participant voted ABORT: the coordinator sends ABORT to every participant.

// Phase 2: Coordinator sends decision
if allYes {
    coordinator.WriteToWAL("COMMIT", txn.ID)
    for _, participant := range participants {
        participant.Commit(txn)
    }
} else {
    for _, participant := range participants {
        participant.Abort(txn)
    }
}

Each participant, upon receiving the decision, applies it (committing or rolling back) and releases its locks. It then sends an ACK back to the coordinator. Once all acknowledgments are received, the coordinator can garbage-collect the transaction record.

The Blocking Problem

The most significant limitation of 2PC is that it is a blocking protocol. If the coordinator crashes after participants have voted COMMIT but before sending the commit decision, participants are stuck. They cannot commit (they don’t know if all other participants also voted yes) and they cannot abort (they already promised to commit). They must hold their locks and wait indefinitely for the coordinator to recover.

Failure Scenarios and Recovery

Participant crashes before voting: The coordinator times out waiting for the vote and aborts the transaction. Safe and straightforward.

Participant crashes after voting yes: On recovery, the participant reads its WAL, sees it voted COMMIT, and contacts the coordinator (or other participants) to learn the outcome. It then commits or aborts accordingly.

Coordinator crashes after collecting votes: This is the dangerous case. If a new coordinator is elected, it must contact all participants to determine who voted what. If even one participant is also down, the new coordinator cannot determine the outcome and must wait.

Network partition: If the coordinator is on one side of a partition and some participants on the other, the isolated participants block until the partition heals.

3PC: An Attempted Fix

Three-Phase Commit (3PC) adds a PRE_COMMIT phase between Prepare and Commit. After all participants vote yes, the coordinator sends PRE_COMMIT to confirm that everyone is prepared. Only then does it send the final COMMIT. This eliminates the ambiguous state where a coordinator crash leaves participants uncertain. 3PC is non-blocking—it places an upper bound on how long a transaction can be in doubt.

However, 3PC adds message complexity (3 round trips instead of 2) and is vulnerable to network partitions in ways that can violate safety. In practice, most distributed databases use 2PC combined with Paxos or Raft-based coordinator replication rather than 3PC.

2PC in Modern Distributed Databases

Modern systems have evolved 2PC to mitigate its weaknesses:

• Google Spanner: Uses 2PC for cross-shard transactions but replicates each participant’s state with Paxos, making both the coordinator and participants highly available. The blocking window effectively vanishes because the coordinator’s decision log is replicated across multiple nodes.
• CockroachDB: Implements a parallel commit optimization where the transaction record and the intent writes are committed simultaneously, reducing 2PC to a single round trip in the common case.
• TiDB/TiKV: Uses a Percolator-style 2PC where the primary key acts as the lock holder and other keys reference it. If the primary commits, all secondaries commit; if it rolls back, all secondaries roll back.

Practical Applications

Atomic Embedding + Metadata Updates

When a document is re-embedded (e.g., after content changes), the system must atomically update the vector in the embedding store and the metadata (version, timestamp, chunk boundaries) in the document database. 2PC ensures that stale embeddings are never served with updated metadata or vice versa.

Multi-Shard Vector Writes

If a document’s chunks are distributed across multiple vector database shards (because different chunks hash to different shards), inserting or deleting the complete document requires a cross-shard transaction. 2PC ensures either all chunks are inserted/deleted or none are, preventing orphaned vectors that return irrelevant search results.

Quota and Billing Consistency

A multi-tenant AI platform that meters API usage (embedding calls, search queries) must atomically execute the operation and decrement the tenant’s quota. Without 2PC, a crash after executing the operation but before recording the usage means the tenant gets free API calls; a crash after recording but before executing means they are charged for nothing.

Key Takeaways

• 2PC guarantees atomicity across multiple nodes: all commit or all abort.
• Phase 1 (Prepare) collects durable votes; Phase 2 (Commit/Abort) enforces the unanimous decision.
• The protocol is blocking—coordinator failure between phases can leave participants holding locks indefinitely.
• Production systems mitigate blocking by replicating the coordinator’s transaction log with Raft or Paxos.
• 3PC eliminates blocking but adds complexity and is rarely used; most systems prefer 2PC + replicated coordinators.
• Modern optimizations (Spanner’s Paxos groups, CockroachDB’s parallel commits, TiKV’s Percolator) reduce 2PC overhead to near single-shard performance.
• For AI infrastructure, 2PC is essential when embedding writes, metadata updates, and accounting operations must be atomic.