Lesson 15 / 32

Distributed Transactions & Sagas

Keeping data correct across services without one shared database.

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.