# Distributed Transactions & Sagas — System Design: Architecture, Scale and Trade-offs

Source: https://www.skillbyai.com/en/system-design/sd-distributed-transactions

> Keep data correct across services using two-phase commit or sagas with compensating actions, and know the trade-offs.

## Why it's hard

A single-database transaction is atomic for free. Once data lives in separate services with separate databases, you need an explicit protocol to make a multi-step operation succeed or fail as a whole.

## Two-phase commit

**2PC** has a coordinator ask every participant to **prepare** (lock and promise to commit), then, only if all say yes, tell everyone to **commit**. It gives strong consistency but blocks if the coordinator dies mid-flight — poor fit for high-scale, high-availability systems.

## The saga pattern

A **saga** breaks the transaction into a sequence of local transactions, each with a **compensating action** to undo it. If step 4 of 5 fails, you run compensations for steps 3, 2, 1 — no locks held across services, but you design for eventual consistency.

## Prefer sagas at scale

Most large systems (e-commerce checkout, travel booking) use sagas orchestrated by a workflow engine or coordinated via events, reserving 2PC for narrow, low-latency scopes like a single database cluster.