Distributed Transactions — 2PC, 3PC, TCC¶

Prerequisites: Architecture Patterns, local ACID transactions

← Architecture Patterns | Sagas covers the practical alternative most systems actually use

Why This Exists¶

Sagas tells you not to use two-phase commit for checkout, and moves on to compensations. That's the right call for payments-plus-carrier-APIs — but it skips the mechanics, and "why not 2PC" only lands if you've seen what 2PC actually is, what it guarantees, and precisely where it breaks. This page is that: the protocol, the coordinator crash that makes it dangerous, 3PC's attempt to fix it, TCC as the pattern people reach for when they want atomicity without XA, and the narrow set of situations where a distributed transaction is still the right answer.

The problem, stated precisely: you have N participants (databases, message brokers, services) and you need all-or-nothing across them — not "eventually all-or-nothing after compensations run," but every participant genuinely commits, or every participant genuinely aborts, with no window where the final outcome could differ between participants.

Precisely what this guarantees, and what it doesn't: 2PC's atomic-commit guarantee is that participants never reach conflicting final decisions — it is never the case that participant A ends up committed while participant B, given the same protocol run, ends up aborted. It does not mean all participants become visibly committed at the same physical instant. Phase 2 sends the COMMIT message to each participant separately, and each executes its own local commit independently, in whatever order messages happen to arrive — participant A can finish committing and become visible to readers milliseconds (or, under a slow network, much longer) before participant B does. An outside observer querying A and B during that window sees exactly the partial-looking state this page's requirements list would seem to rule out: A already reflects the new balance, B still shows the old one — even though both will end up committed, and the protocol never risked one committing while the other aborted. Preventing that visibility gap (true global isolation across participants) needs coordination beyond atomic commit itself — e.g. a global lock held until every participant confirms, or routing all reads through a component that knows the transaction hasn't fully settled. 2PC alone buys you consistent outcomes; it doesn't buy you simultaneous visibility.

BEGIN DISTRIBUTED TRANSACTION
  Account service:   debit $100 from Alice
  Ledger service:     credit $100 to Bob
  Audit service:       write "transfer #4471"
COMMIT  -- either all three happen, or none do, full stop

A single-database BEGIN...COMMIT gives you this for free via the DB's own WAL and locking. Across three databases, you need a protocol that makes participants agree — and that agreement is the entire hard part.

Two-Phase Commit (2PC)¶

Phase 1: Prepare (vote)¶

The coordinator asks every participant: "Can you commit this?" Each participant does everything short of actually committing — validates constraints, writes to its own durable log, acquires and holds every lock it would need — then replies YES (prepared, promise to commit if told) or NO (abort).

Phase 2: Commit or Abort (decide)¶

If all participants voted YES, the coordinator durably logs "commit" and tells everyone to commit. If any voted NO (or timed out), the coordinator tells everyone to abort. Participants obey unconditionally — a YES vote in phase 1 is a binding promise, not a suggestion.

sequenceDiagram
    participant C as Coordinator
    participant A as Participant: Accounts DB
    participant L as Participant: Ledger DB

    Note over C,L: Phase 1 — PREPARE (vote)
    C->>A: PREPARE
    C->>L: PREPARE
    A->>A: validate, write to log,<br/>acquire locks, hold them
    L->>L: validate, write to log,<br/>acquire locks, hold them
    A-->>C: YES
    L-->>C: YES

    Note over C: All YES → decision = COMMIT<br/>(coordinator durably logs this BEFORE telling anyone)

    Note over C,L: Phase 2 — COMMIT (decide)
    C->>A: COMMIT
    C->>L: COMMIT
    A->>A: commit, release locks
    L->>L: commit, release locks
    A-->>C: ACK
    L-->>C: ACK

Where it blocks¶

sequenceDiagram
    participant C as Coordinator
    participant A as Participant: Accounts DB
    participant L as Participant: Ledger DB

    C->>A: PREPARE
    C->>L: PREPARE
    A-->>C: YES (locks held)
    L-->>C: YES (locks held)
    Note over C: Coordinator CRASHES here —<br/>after collecting votes, before Phase 2

    rect rgb(80, 20, 20)
    Note over A,L: A and L are PREPARED: locks held,<br/>cannot unilaterally commit or abort.<br/>They do not know what the other voted.<br/>They wait. Every row those locks touch<br/>is unavailable until the coordinator recovers.
    end

This is the defining flaw: a participant that has voted YES cannot safely decide anything on its own — committing when the real decision was abort creates a permanent inconsistency, and aborting when the real decision was commit does too. It must wait for the coordinator. If the coordinator is gone for good (disk failure, and its log didn't survive), the participants are stuck indefinitely, holding locks, until a human intervenes — this is called the blocking problem, and it's why 2PC has a bad reputation for availability.

Three-Phase Commit (3PC): the attempted fix¶

3PC splits phase 2 into pre-commit and commit, and adds timeouts so participants can make progress without the coordinator:

Phase 1: PREPARE       — same as 2PC, collect votes
Phase 2: PRE-COMMIT     — coordinator tells everyone "commit is coming" (not yet final)
Phase 3: COMMIT         — coordinator tells everyone to actually commit

The idea: if a participant has reached pre-commit, it knows every other participant also voted YES (that's why pre-commit was sent), so if the coordinator now vanishes, that participant can safely time out and commit on its own — it has enough information to know commit is the only outcome anyone could be waiting for.

Why it's rarely used in practice: 3PC assumes the network is not just eventually reliable but synchronous enough that a timeout reliably distinguishes "coordinator crashed" from "message is just slow." Under a network partition — the exact condition CAP theorem says you must tolerate — a participant can time out and commit while, on the other side of the partition, the coordinator (still alive) decided to abort. Now you have a split-brain: some participants committed, some aborted, and nobody agrees. 3PC trades the blocking problem for a correctness problem under partitions, which is a worse trade for most systems. It shows up in distributed-systems courses and papers; it does not show up in production stacks the way 2PC (via XA) still occasionally does.

XA: 2PC's real-world plumbing¶

XA is the actual standard (X/Open, adopted by JTA in Java, and supported by Postgres, MySQL, most message brokers) that implements 2PC across heterogeneous resource managers (RMs) — different databases, a DB and a queue, etc. — coordinated by a transaction manager.

Transaction Manager (coordinator)
   │
   ├── XA RM: PostgreSQL connection   (xa_start, xa_end, xa_prepare, xa_commit)
   ├── XA RM: MySQL connection
   └── XA RM: message broker (JMS)

Where XA actually gets used today: mostly within a single organization's infrastructure, same datacenter or low-latency LAN, same vendor stack or a small set of XA-compliant resources — think a legacy Java EE app coordinating a DB write and a JMS message send atomically. It essentially never spans external services: Stripe will not join your XA transaction, and no SaaS API exposes a prepare verb. That's the concrete reason Sagas opens with "that option was never real" for payment-plus-warehouse-plus-carrier — XA requires every participant to speak the protocol, and most of the systems you integrate with over the internet simply don't.

TCC (Try-Confirm/Cancel): application-level reservations without locks¶

TCC approximates 2PC-style atomicity without holding DB locks across the network, by pushing the "reservation" into application logic instead of database row locks — approximates, because as the warning below covers, Confirm is not actually one atomic cross-participant step the way 2PC's phase 2 is:

Try:      Accounts:  reserve $100 (available -= 100, but balance unchanged)
          Ledger:    reserve credit slot for Bob
Confirm:  Accounts:  balance -= 100 (release reservation, apply real debit)
          Ledger:    balance += 100
-- or, if Ledger's Try had failed —
Cancel:   Accounts:  release reservation (available += 100, balance untouched)

This is genuinely different from 2PC's locks: a "Try" reservation is application state (a row saying "$100 reserved, expires in 30s"), not a database lock — other transactions can still see and reason about the account, and an unconfirmed reservation expires on its own via TTL instead of blocking forever. The cost: you write Try/Confirm/Cancel for every operation by hand — there's no generic driver-level support the way XA gives you for 2PC. It's a real pattern in payments and inventory systems (Alibaba's TCC frameworks, several open-source Seata-style implementations) precisely because "reserve, then confirm" maps naturally onto "authorize, then capture" — which most payment APIs already support as a first-class concept.

Comparison¶

When a Distributed Transaction Is Still the Right Call¶

Despite everything above, 2PC/XA is not obsolete — it's just narrowly scoped:

• Same datacenter, low-latency LAN, small number of participants — the blocking window is milliseconds, not "however long a flaky carrier API takes," so the risk of a coordinator crash landing in that tiny window is genuinely low.
• All participants are internal and XA-compliant — no third-party API in the chain that can't speak the protocol.
• The business genuinely cannot tolerate a visible intermediate state — sagas expose PAID_UNSHIPPED-style states as real, queryable facts; if literally no consumer of that data can be allowed to see a partial result, 2PC's "nothing is visible until everyone agrees" property is the only one that provides it.
• A short-lived internal transaction manager already exists in the stack (e.g., Java EE / Spring's JTA), and adding XA to one more resource is cheap compared to building sagas or TCC compensations for something that rarely needs cross-service atomicity in the first place.

The interview-safe framing: default to sagas or TCC for anything crossing an organizational or network boundary you don't fully control; reach for 2PC/XA only when every participant is internal, the round-trip is short, and the org already has the transaction-manager infrastructure to run it safely.

Failure Modes¶

Interview Questions¶

Key Takeaways¶

Previous: Architecture Patterns | Next: Sagas