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^[1]. Sagas give you availability and long-running durability but sacrifice isolation: observers see partial state between steps^[2]. TCC gives stronger isolation than Saga via resource reservations but triples the code surface per operation^[3]. 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^[4][5].

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)^[1:1][4:1]. 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^[1:2]. 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^[4:2].

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.

The window between prepare-ack and commit is where a coordinator crash leaves participants holding locks indefinitely, the fundamental blocking problem of 2PC.

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^[8]. TCC is niche: Seata is the only major open-source implementation, and its fence-log plumbing is non-trivial^[7:1].

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^[9][10].

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^[6: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^[2:2][11].

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^[8:1]. 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^[8:2].

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.

The outbox row is committed atomically with the business change; Debezium tails the WAL and publishes to Kafka, avoiding any distributed transaction.

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^[12]. Consumers handle at-least-once delivery via idempotency keys (Stripe prunes its Idempotency-Key entries after at least 24 hours^[5:1]). The orchestrator (Temporal, Cadence) coordinates the saga sequence, persisting every workflow event for replay on failure^[8:3][13].

This is not exotic. Stripe, Uber, and virtually every modern payment system operates this way^{[5:2][14][15]}.

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^[9:1][10:1]. Cloud Spanner recommends a 20-100 ms commit delay for throughput optimization^[16]. 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^[6:2]. The protocol was formally verified in TLA+ with a safety property (AckImpliesCommit) and a liveness property (ImplicitCommitLeadsToExplicitCommit)^[6:3].

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^[8:4]. Payment workflows use orchestrated sagas where each step (auth, capture, settle, refund) has an explicit compensation^[14:1][15:1].

Common Mistakes#

Decision Checklist#

Decision flowchart: most microservices land on Saga + outbox; 2PC is reserved for database internals or strict-ACID short transactions.

• 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^[4:3].

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#