# System Design: Distributed Transactions — Two-Phase Commit, Saga, and Eventual Consistency

Source: https://www.techinterview.org/post/3233464776/system-design-distributed-transaction/
Updated: 2026-04-17 · techinterview.org

## The Problem with Distributed Transactions

In a monolith with a single database, ACID transactions guarantee atomicity: either all operations succeed or none do. In a microservices architecture, a single business operation (e.g., place an order: reserve inventory, charge payment, notify shipping) spans multiple services with separate databases. Traditional ACID transactions do not work across service boundaries. Three solutions: Two-Phase Commit (2PC), Saga pattern, and Eventual Consistency with idempotent operations.

## Two-Phase Commit (2PC)

**Phase 1 (Prepare)**: a Coordinator sends PREPARE to all participants. Each participant logs that it is prepared (durable write), replies with YES/NO. **Phase 2 (Commit/Abort)**: if all say YES, Coordinator sends COMMIT; participants commit and release locks. If any says NO, Coordinator sends ABORT; all participants rollback.

Problems with 2PC: (1) Blocking protocol -- if the Coordinator crashes after Phase 1 but before Phase 2, participants are stuck holding locks indefinitely (blocking 2PC). (2) Single point of failure -- the Coordinator is critical. (3) Poor performance -- two round trips plus durable writes at every step. (4) Does not work well across WAN (high latency, unreliable links). Used within a single data center for databases that support it (PostgreSQL supports 2PC with PREPARE TRANSACTION).

## Three-Phase Commit (3PC)

Adds a pre-commit phase between Prepare and Commit to make the protocol non-blocking. Rarely used in practice -- adds complexity and latency. Real-world systems use Paxos or Raft for consensus instead of 3PC.

## Saga Pattern

A saga is a sequence of local transactions with compensating transactions for rollback. No global lock -- each step commits independently. Two implementations:

**Choreography**: each service publishes an event on success; the next service listens and acts. On failure: the failing service publishes a failure event; upstream services listen and execute compensating transactions. Pro: no central coordinator. Con: difficult to trace and reason about for complex flows.

**Orchestration**: a Saga Orchestrator sends commands to each service and handles failures centrally. Easier to monitor. The orchestrator maintains saga state (which steps completed, which are pending) in a database. Used by Uber (Money saga), Netflix (subscription workflows).

Saga limitations: no isolation (intermediate states are visible to other transactions), compensations must be designed carefully (some operations are hard to compensate -- e.g., sent emails cannot be unsent).

## Idempotency and At-Least-Once Delivery

In distributed systems, messages may be delivered more than once (network retries). Services must be idempotent: processing the same message twice produces the same result as processing it once. Implement with idempotency keys: store (idempotency_key, result) in a database. On receipt: check if key exists. If yes, return stored result. If no, process and store. This is the foundation of reliable distributed processing.

## Eventual Consistency

In many systems, strict consistency is unnecessary. Eventual consistency: after all updates propagate, all replicas converge to the same value. Acceptable for: social media feeds (showing a post to some users before others), DNS propagation (takes minutes), product catalog (pricing may lag by seconds). Not acceptable for: bank account balances, inventory reservation (must be exact), payment processing.

## Choosing the Right Approach

| Approach | Consistency | Availability | Complexity | Use When |
| --- | --- | --- | --- | --- |
| 2PC | Strong | Low | Medium | Same datacenter, short transactions |
| Saga (choreography) | Eventual | High | Medium | Independent services, simple flows |
| Saga (orchestration) | Eventual | High | High | Complex multi-step workflows |
| Eventual consistency | Eventual | Very High | Low | Non-critical reads, high-scale |

Asked at: [Stripe Interview Guide](https://techinterview.org/stripe-interview/)

Asked at: [Coinbase Interview Guide](https://techinterview.org/coinbase-interview/)

Asked at: [Shopify Interview Guide](https://techinterview.org/shopify-interview/)

Asked at: [Databricks Interview Guide](https://techinterview.org/databricks-interview/)

Asked at: [Netflix Interview Guide](https://techinterview.org/netflix-interview/)