Distributed Transactions: 2PC vs Saga vs TCC

TL;DR. Two-phase commit (2PC) gives you ACID atomicity across services but blocks on coordinator failure and holds locks for two network round-trips¹. Sagas give you availability and long-running durability but sacrifice isolation: observers see partial state between steps². TCC gives stronger isolation than Saga via resource reservations but triples the code surface per operation³. The deciding dimension is how much intermediate-state visibility the business can tolerate. For most microservices in 2025, the default is Saga + transactional outbox + idempotency keys⁴⁵.

Learning Objectives

• Compare 2PC, Saga, and TCC across isolation, availability, latency, and implementation cost.
• Identify workload characteristics (duration, participant control, reversibility) that favor each approach.
• Justify the Saga + outbox + idempotency hybrid as the modern microservices default.
• Evaluate Spanner, CockroachDB, and Uber Cadence as production decision examples.

The Core Trade-off

Any protocol that coordinates commit across N nodes must either block until all participants respond (hurting availability) or allow participants to make independent local decisions that may later need compensation (hurting isolation)¹⁴. There is no third option. Gray and Lamport showed that only a consensus-backed commit protocol (Paxos Commit) avoids the blocking problem of classical 2PC by running Paxos among 2F+1 acceptors per participant¹. Helland went further, arguing that the failure of a single node causes transaction commit to stall, and the larger the system gets, the more likely it is to be down⁴.

The metric that moves in opposite directions is isolation vs. availability. Strengthen isolation (2PC holds locks across all participants) and availability drops because any participant failure blocks the entire transaction. Weaken isolation (Saga commits each step independently) and availability rises because no cross-service locks exist, but observers see intermediate states.

sequenceDiagram
    participant C as Coordinator
    participant P1 as Participant 1
    participant P2 as Participant 2
    C->>P1: PREPARE
    C->>P2: PREPARE
    P1-->>C: VOTE YES (locks held)
    P2-->>C: VOTE YES (locks held)
    Note over C: Crash here leaves<br/>P1, P2 blocked indefinitely
    C->>P1: COMMIT
    C->>P2: COMMIT
    P1-->>C: ACK
    P2-->>C: ACK

Side-by-Side Comparison

The table understates one dimension: operational maturity. 2PC is well-understood inside a single database (Spanner, CockroachDB handle it transparently). Saga tooling (Temporal, Cadence) is production-grade but requires workflow-determinism discipline⁸. TCC is niche: Seata is the only major open-source implementation, and its fence-log plumbing is non-trivial⁷.

When to Pick 2PC

Strict ACID is a regulatory requirement. Financial reconciliation, double-entry ledger commits, compliance systems where partial commit is a breach. Google Spanner uses 2PC over Paxos groups with TrueTime to deliver external consistency at global scale⁹¹⁰.

Transaction duration is short (sub-second). 2PC holds locks across all participants until decision. CockroachDB Parallel Commits halves the latency from 2 consensus round-trips to 1⁶, making short cross-range transactions practical.

All participants are under your operational control. 2PC requires every participant to implement the prepare-commit interface. External APIs (Stripe, Twilio, SendGrid) do not expose XA.

You are building a database, not using one. If you control the storage layer, Paxos Commit eliminates the blocking problem. Spanner, CockroachDB, and TiDB all run 2PC internally so application developers never see it.

When to Pick Saga

Long-running business processes spanning services. Order fulfillment, travel booking, employee onboarding. Each step commits locally; the orchestrator tracks progress across minutes or days²¹¹.

Third-party APIs are involved. Stripe charges, email sends, SMS dispatches. These cannot participate in 2PC but can be compensated (refund, retract, cancel).

Eventual consistency is acceptable. Between step N success and step N+1 attempt, observers see partial state. If the business can tolerate “order placed but payment pending” for seconds, Saga works.

The team uses Temporal, Cadence, or Step Functions. These orchestrators persist workflow state durably, retry activities with backoff, and make compensation sequences debuggable⁸. Uber reports that Cadence powers over 1,000 services internally and runs over 12 billion workflow executions and 270 billion actions per month, spanning long-running workflows, microservice orchestration, and distributed cron⁸.

The Hybrid Path

The 2025-era production default is not pure Saga, pure 2PC, or pure TCC. It is: Saga orchestration + transactional outbox + idempotency keys. This combination gives at-least-once atomicity between state changes and events without any distributed transaction protocol.

flowchart LR
    App[Service] -->|"1. INSERT order + outbox row<br/>in one local TX"| DB[(Postgres)]
    DB -->|"2. WAL"| Debezium[Debezium CDC]
    Debezium -->|"3. outbox.event.order"| Kafka[(Kafka)]
    Kafka --> Consumer[Downstream service<br/>idempotent handler]

The service inserts into an outbox table inside the same local transaction as the business write. Debezium reads the WAL and routes each row to the correct Kafka topic¹². Consumers handle at-least-once delivery via idempotency keys (Stripe prunes its Idempotency-Key entries after at least 24 hours⁵). The orchestrator (Temporal, Cadence) coordinates the saga sequence, persisting every workflow event for replay on failure⁸¹³.

This is not exotic. Stripe, Uber, and virtually every modern payment system operates this way⁵¹⁴¹⁵.

Real-World Examples

Google Spanner (2PC over Paxos + TrueTime). Spanner shards data into Paxos groups replicated across 3-5 zones. A read-write transaction acquires locks at each Paxos leader, picks a commit timestamp using TrueTime’s bounded uncertainty, and performs 2PC where the coordinator itself is Paxos-replicated⁹¹⁰. Cloud Spanner recommends a 20-100 ms commit delay for throughput optimization¹⁶. This is 2PC done right: the blocking problem is eliminated by consensus, but it requires GPS + atomic clock infrastructure.

CockroachDB Parallel Commits. CockroachDB reworked 2PC so a transaction writes a STAGING record plus intent writes concurrently. The transaction is “implicitly committed” the moment all achieve Raft consensus, cutting latency from 2x inter-node RTT to 1x RTT⁶. The protocol was formally verified in TLA+ with a safety property (AckImpliesCommit) and a liveness property (ImplicitCommitLeadsToExplicitCommit)⁶.

Uber Cadence (Saga orchestration). Cadence durably records every workflow event to a sharded persistence layer, powering long-running workflows, microservice orchestration, and distributed cron across more than 1,000 services at Uber at 12+ billion executions per month⁸. Payment workflows use orchestrated sagas where each step (auth, capture, settle, refund) has an explicit compensation¹⁴¹⁵.

Common Mistakes

Decision Checklist

flowchart TD
    Start[Need atomicity across<br/>services or DBs?]
    Start -->|No| Mono[Keep in one service /<br/>one DB transaction]
    Start -->|Yes| Q1{All participants<br/>under your control?}
    Q1 -->|No| Saga[Saga + outbox +<br/>idempotency keys]
    Q1 -->|Yes| Q2{Duration > seconds?}
    Q2 -->|Yes| Saga
    Q2 -->|No| Q3{Resources support<br/>reservations?}
    Q3 -->|Yes| TCC[TCC]
    Q3 -->|No| Q4{Strict ACID<br/>required?}
    Q4 -->|Yes| TwoPC[2PC over Paxos<br/>Spanner / CockroachDB]
    Q4 -->|No| Saga

• Can the business survive intermediate-state visibility between steps? If no, keep it in one service.
• Can each step be compensated, and is the compensator idempotent and reversible?
• What is the expected duration? 2PC caps at seconds; Saga handles days.
• Are all participants under your operational control, or are third-party APIs involved?
• Is at-least-once delivery with app-level idempotency acceptable?
• Do resources support a native reservation primitive (seats, inventory, calendar holds)?
• Does the team have Temporal/Cadence operational experience?

Key Takeaways

• 2PC gives ACID but blocks on failure and caps at sub-second durations. Use it inside databases (Spanner, CockroachDB), not across microservices.
• Saga gives availability and handles long-running flows but sacrifices isolation. Compensations are forward recovery, not rollback.
• TCC gives stronger isolation than Saga via reservations but triples code surface and requires all participants to expose Try/Confirm/Cancel.
• The modern default is Saga + transactional outbox + idempotency keys + orchestrator (Temporal/Cadence). This is not exotic; it is mainstream.
• Helland’s rule holds: at scale, avoid distributed transactions entirely. Build from independent entities linked by at-least-once messaging with app-level idempotency⁴.

Further Reading

• Consensus on Transaction Commit (Gray and Lamport, 2006): Paxos Commit, the non-blocking replacement for classic 2PC, foundational to Spanner and CockroachDB.
• Life Beyond Distributed Transactions (Helland, 2016): the canonical argument for replacing DTX with entities, activities, and at-least-once messaging.
• Parallel Commits (VanBenschoten, Cockroach Labs): CockroachDB’s 1-RTT 2PC with TLA+ verification; the state of the art in optimized atomic commit.
• Designing robust APIs with idempotency (Stripe): Stripe’s canonical idempotency-key pattern that makes saga retries safe.
• To choreograph or orchestrate your saga (Temporal): the mainstream pro-orchestration argument with concrete Temporal examples.
• Debezium Outbox Event Router: CDC-backed outbox implementation that eliminates dual-write problems.

Flashcards

References