2PC: Two-Phase Commit Protocol

Two-phase commit (2PC) is an algorithm for achieving atomic transaction commit in a distrubuted systems. All participating nodes must either successfully commit or abort together. This protocol (a specialised type of consensus protocol) achieves its goal even in many cases of temporary system failure (involving either process, network node, communication, etc. failures), and is thus widely used.

One node acts as the coordinator, also called the transaction manager, to initiate 2PC. The algorithm has two phases:

• Prepare phase: Ask the other nodes whether they can commit the proposed transaction.
• Commit phase: Instruct the other nodes to either commit or abort the proposed transaction.

Example: Placing an order

Consider a food delivery app with over 6M users base that promises delivery in 10 minutes. When a customer places an order, the order can be confirmed only if both item and delivery partner are both available, else can’t. Let’s say they have a microservice, with Order Service cordinating the order, Inventory service to manage inventory and Devlivery Agent service to manage the agents. Order is confirmed only when inventory and delivery agent service both send a consensus to order service. The Order Service acts as the coordinator. Each participant must durably prepare its transaction before voting to commit, and the coordinator must durably record its decision before sending the global commit.

sequenceDiagram
    autonumber
    actor User
    participant O as Order Service
    participant S as Store Service
    participant D as Delivery Agent Service

    User->>O: Click "Place Order"

    Note over O,D: PHASE 1: Prepare Phase (Locks & Validation)
    O->>O: Create Order in "PENDING" state
    O->>S: Prepare: Reserve inventory items?
    O->>D: Prepare: Lock available delivery agent?
    S-->>O: VOTE_COMMIT (Inventory locked, prepared durably)
    D-->>O: VOTE_COMMIT (Agent reserved, prepared durably)

    Note over O,D: PHASE 2: Commit Phase (Final Execution)
    O->>O: Durably record COMMIT decision
    O->>O: Change state to "CONFIRMED / PLACED"
    O->>S: Global Commit: Finalize inventory deduction
    O->>D: Global Commit: Assign agent to order
    S-->>O: Acknowledged
    D-->>O: Acknowledged

    O-->>User: Order Placed Successfully!

Pros

• Atomic transactions: All participants agree to commit or abort.
• ACID Compliance: The shared outcome helps preserve constraints across services when each participant validates its own changes.

Cons

• Coordination and durable writes add latency.
• Holding resource locks can lead to deadlock.
• Prepared participants can remain blocked if the coordinator’s decision is unavailable.

A deadlock example

Order A holds Store 1’s pizza inventory and waits for Delivery Agent X. Order B holds Delivery Agent X and waits for the same inventory. Neither transaction can acquire all its resources without intervention.

sequenceDiagram
    autonumber
    participant OA as Order Service A
    participant OB as Order Service B
    participant S1 as Store Service 1 (Pizza)
    participant D as Delivery Service (Agent X)

    rect rgb(245, 245, 245)
        Note over OA, D: Step 1: Resource acquisition begins for both transactions
        OA->>S1: Tx A: Lock Pizza Inventory
        S1-->>OA: Pizza inventory locked for Tx A

        OB->>D: Tx B: Lock Delivery Agent X
        D-->>OB: Agent X locked for Tx B
    end

    rect rgb(245, 245, 245)
        Note over OA, D: Step 2: Mutual blocking (Deadlock)
        OA->>D: Tx A: Try to Lock Agent X...
        Note over D: Tx A blocks! Agent X is locked by Tx B.

        OB->>S1: Tx B: Try to Lock Pizza Inventory...
        Note over S1: Tx B blocks! Pizza is locked by Tx A.
    end

    Note over OA, OB: Neither transaction can acquire <br/> all resources.A timeout or <br/> deadlock detector can <br/>trigger an abort before a <br/> commit decision is recorded.

Lock acquisition is shown separately from the final prepared vote here. A participant that has already voted to commit cannot independently abandon its prepared transaction.

How systems handle deadlock

• Timeouts before the commit decision: A coordinator waiting for votes can choose to abort when its deadline expires. A participant may abort before voting yes. After voting yes, it cannot safely force an abort just because a timeout expires; it must learn the global decision through the coordinator or recovery protocol.
• Strict resource ordering: Require every transaction to acquire resources in the same global order, including individual resources within each service. For example, always lock store inventory before delivery agents. Consistent ordering prevents circular waits.
• The Saga pattern as an alternative: Use a sequence of local transactions with compensating actions when a later step fails. Sagas avoid holding distributed transaction locks across the entire workflow, but intermediate changes can be visible and compensation replaces atomic rollback.