Prerequisites

The Atomic Commitment Problem

A single database makes atomicity straightforward: one log, one commit point, one recovery procedure. The problem changes entirely when a transaction spans several independent systems, each with its own log and its own failures.

The Two Phases

async function twoPhaseCommit(coordinator, participants, transaction) {
    const txId = coordinator.newTransactionId();

    // Phase one: solicit votes
    const votes = await Promise.allSettled(
        participants.map(p => p.prepare(txId, transaction.workFor(p.id)))
    );

    const allAgreed = votes.every(
        v => v.status === "fulfilled" && v.value.vote === "yes"
    );

    // Decision point: this log write is irreversible
    const decision = allAgreed ? "commit" : "abort";
    await coordinator.logDecision(txId, decision);

    // Phase two: propagate until every participant acknowledges
    const outcomes = await Promise.allSettled(
        participants.map(p =>
            decision === "commit" ? p.commit(txId) : p.abort(txId)
        )
    );

    const unacknowledged = outcomes
        .map((o, i) => ({ outcome: o, participant: participants[i] }))
        .filter(x => x.outcome.status !== "fulfilled");

    if (unacknowledged.length > 0) {
        await coordinator.scheduleRecovery(txId, decision, unacknowledged);
    }

    return { txId, decision, pendingRecovery: unacknowledged.length };
}

A Yes Vote Cannot Be Withdrawn

The property that makes 2PC work is also what makes it painful. Voting yes surrenders autonomy: the participant can no longer decide its own outcome.

The Blocking Problem

This is the defining weakness of 2PC and the reason it is classified as a blocking protocol. It is not a bug to be fixed but a consequence of the protocol's structure.

Cascading Impact

Durable State Requirements

Recovery depends entirely on what was written to stable storage before each failure. Both sides must log at specific points.

CREATE TABLE coordinator_log (
    transaction_id  VARCHAR(80) PRIMARY KEY,
    decision        VARCHAR(10) NOT NULL,
    participants    JSONB       NOT NULL,
    decided_at      TIMESTAMP   NOT NULL,
    completed_at    TIMESTAMP   NULL
);

CREATE TABLE participant_log (
    transaction_id  VARCHAR(80) PRIMARY KEY,
    state           VARCHAR(20) NOT NULL,
    coordinator_id  VARCHAR(80) NOT NULL,
    redo_payload    JSONB       NOT NULL,
    prepared_at     TIMESTAMP   NOT NULL,
    resolved_at     TIMESTAMP   NULL
);

-- Recovery: find transactions stuck in doubt
SELECT transaction_id,
       coordinator_id,
       prepared_at,
       CURRENT_TIMESTAMP - prepared_at AS in_doubt_duration
FROM participant_log
WHERE state = 'prepared'
  AND resolved_at IS NULL
ORDER BY prepared_at;

Recovery

async function recoverParticipant(participant) {
    const inDoubt = await participant.log.findPrepared();

    for (const tx of inDoubt) {
        const coordinator = await participant.locate(tx.coordinatorId);

        if (!coordinator.reachable) {
            participant.metrics.recordBlocked(tx.transactionId);
            continue;
        }

        const outcome = await coordinator.queryOutcome(tx.transactionId);

        switch (outcome.decision) {
            case "commit":
                await participant.commit(tx.transactionId);
                break;

            case "abort":
                await participant.abort(tx.transactionId);
                break;

            case "unknown":
                // Coordinator has no record: it failed before deciding
                await participant.abort(tx.transactionId);
                break;

            default:
                participant.metrics.recordBlocked(tx.transactionId);
        }
    }
}

Heuristic Decisions

When blocking becomes intolerable, an operator may force an outcome manually. This restores availability by abandoning the atomicity guarantee.

Reducing the Blocking Window

Consensus-Backed Coordinators

Three-Phase Commit

The Cost

Alternatives

Most systems that reach for 2PC would be better served by an approach that avoids distributed atomicity altogether.

When 2PC Is Appropriate

Monitoring

Verification

describe("two-phase commit", function () {
    it("aborts when any participant votes no", async function () {
        const result = await coordinator.execute(transaction, {
            participants: [okParticipant, refusingParticipant]
        });

        expect(result.decision).toBe("abort");
        expect(await okParticipant.applied(result.txId)).toBe(false);
    });

    it("holds locks while prepared", async function () {
        await participant.prepare(txId, work);

        const conflicting = participant.execute(conflictingWork);

        await expect(
            Promise.race([conflicting, timeout(1000)])
        ).resolves.toBe("timeout");
    });

    it("resumes after coordinator restart", async function () {
        await coordinator.prepareAll(txId, participants);
        await coordinator.logDecision(txId, "commit");

        await faultInjector.crashCoordinator();
        await coordinator.restart();
        await coordinator.runRecovery();

        for (const p of participants) {
            expect(await p.state(txId)).toBe("committed");
        }
    });

    it("blocks rather than diverging when coordinator is lost", async function () {
        await coordinator.prepareAll(txId, participants);
        await faultInjector.destroyCoordinator();

        for (const p of participants) {
            expect(await p.state(txId)).toBe("prepared");
        }
    });
});

Common Design Mistakes

System Design Interview Discussion

Design Checklist

Knowledge Check

Summary

Two-phase commit achieves atomic commitment across independent systems by separating agreement from execution. Participants vote in the prepare phase, the coordinator records a decision durably, and that decision is then delivered for application.

The property that makes it work is that a yes vote is irrevocable. A prepared participant surrenders autonomy, holding locks and refusing conflicting work until told the outcome. This is also what makes the protocol blocking: if the coordinator fails after votes are collected, prepared participants cannot safely decide alone.

Blocking is structural rather than a defect. A prepared participant that timed out and aborted might diverge from a peer that already committed. The practical remedy is a consensus-backed decision log, so no single coordinator failure leaves anyone in doubt.

The costs are substantial: two round trips, a durable write per participant, locks held across the network, and availability that compounds downward with each participant added. Most systems should first consider sagas, the transactional outbox, or redrawing service boundaries so the atomic change lives in one place.