Distributed Transactions Explained: 2 Phase Commit vs Saga Pattern

🧠 Want more system design content? Head over to  https://www.hellointerview.com/youtube/distributed-transactions

Once you shard your data across services, a single business operation can span multiple machines — and ACID guarantees fall apart. This video breaks down the two textbook solutions, two-phase commit and the Saga pattern, and explains why the industry has overwhelmingly moved toward one of them.

We cover how 2PC actually works (prepare, vote, commit) and why it falls over in production: blocking participants, held locks, coordinator crashes, and one slow service freezing the whole transaction. Then we get into Sagas — chains of local transactions with compensating actions — including choreography vs orchestration, the hard parts of compensation, and the transactional outbox pattern that makes Sagas reliable in practice.

Key takeaway: 2PC across services is a textbook concept, not a production pattern. For cross-service transactions, use a Saga (usually orchestration with something like Temporal or Step Functions) plus idempotent operations and the outbox pattern. If you truly need strong consistency across data stores, reach for a distributed database like Spanner or CockroachDB that handles 2PC internally — don't build it yourself.

Connect with me on LinkedIn! https://www.linkedin.com/in/evan-king-40072280/

Learn more at https://www.hellointerview.com/learn/system-design/patterns/dealing-with-contention#multiple-nodes

Related videos:
CAP Theorem in System Design Interviews https://www.youtube.com/watch?v=VdrEq0cODu4