The Old Way: Two-Phase Commit (2PC)

The Wedding Analogy

How do you get multiple independent parties to agree on a single, atomic action? You use a coordinator. The classic approach is the Two-Phase Commit (2PC) protocol — a distributed algorithm designed to ensure all participants in a transaction either commit or rollback together.

Think of it like a wedding ceremony. The officiant (coordinator) asks both parties (participants) if they consent before the marriage is legally recorded.

Phase 1: The Prepare Phase

The Coordinator sends a "Prepare" message to all Participants (each database or service involved in the transaction).

Each participant must:
1. Check whether it can complete its part of the transaction.
2. Acquire the necessary locks on the data it will modify — preventing any other transaction from changing that data.
3. Write the pending changes to a durable log (so it can recover if it crashes).
4. Reply with either "Yes, I'm ready to commit" or "No, I cannot commit."

Critically, after voting "Yes," a participant is locked in. It has promised to commit if the coordinator says so, and it is holding locks on its data while it waits.

Phase 2: The Commit Phase

The Coordinator collects all votes:
- If all participants voted "Yes": The Coordinator writes "Commit" to its own log, then sends a COMMIT message to all participants. Each participant finalizes the write and releases its locks.
- If any participant voted "No" (or timed out): The Coordinator sends a ROLLBACK message to all participants. Each participant discards its pending changes and releases its locks.

Coordinator          Participant A        Participant B
    |                     |                    |
    |--- PREPARE -------->|                    |
    |--- PREPARE -------->|------------------->|
    |                     |                    |
    |<-- VOTE: YES -------|                    |
    |<-- VOTE: YES ----------------------- ----|
    |                     |                    |
    |--- COMMIT --------->|                    |
    |--- COMMIT --------->|------------------->|
    |                     |                    |
    |<-- ACK -------------|                    |
    |<-- ACK ------------------------------ ---|

Why We Don't Use It Anymore

2PC provides strong consistency, but it has a fatal flaw for modern distributed systems: it is a blocking protocol.

Between a participant voting "Yes" and receiving the final COMMIT or ROLLBACK, that participant is stuck — holding locks on its data, unable to serve other requests. If the Coordinator crashes or the network partitions during this window, participants are left in a "in-doubt" state: they voted Yes, they're holding locks, but they don't know whether to commit or rollback. They must wait for the coordinator to recover, which could take minutes or longer.

This blocking behavior means:
- Availability suffers: Locked rows cannot be read or written by other transactions.
- Scalability suffers: Lock contention grows as traffic increases.
- Fragility: A single coordinator failure can freeze multiple databases simultaneously.

2PC works acceptably in tightly controlled environments (like a single data center with reliable networks), which is why some traditional enterprise systems still use it. But for internet-scale microservices, it is a poor fit.