Distributed Transactions (2PC & Saga)
ReliabilityTechniques for keeping multiple services/databases consistent when a single logical operation must update more than one of them.
A single-database transaction gives you atomicity for free (ACID). Once state is split across multiple services/databases (as in microservices), a logical operation that must touch several of them (e.g. 'reserve inventory AND charge payment AND create shipment') no longer has a built-in all-or-nothing guarantee. Two-Phase Commit (2PC) is the classic strong-consistency answer: a coordinator asks all participants to 'prepare' (lock resources, promise they *can* commit), and only if everyone says yes does it tell everyone to actually commit — strongly consistent, but blocking (a crashed coordinator can leave participants holding locks indefinitely) and doesn't scale well across many services. The Saga pattern is the more common modern answer: break the operation into a sequence of local transactions, each with a corresponding compensating action to undo it — if step 3 of 5 fails, you run the compensations for steps 2 and 1 to unwind what already happened, achieving eventual (not immediate) consistency without ever holding cross-service locks.
How it connects
Distributed Transactions (2PC & Saga) as the source, with the components it typically interacts with.
- → Database Types (SQL, NoSQL & Beyond): Distributed transactions (2PC/sagas) exist specifically to keep multiple database shards or services consistent when a single operation spans them.
- → Message Queues & Event Streaming: The saga pattern is typically implemented by publishing compensating events to a queue so each service can react and roll back its own step on failure.
- → Consensus & Replication Protocols: Two-phase commit's coordinator role and failure-recovery logic mirror consensus algorithms, and some implementations reuse a consensus store to make the decision durable.