---
title: 'Distributed Transactions'
source: 'https://youtube.com/watch?v=5wiJvT7EY3o'
video_id: '5wiJvT7EY3o'
date: 2026-08-04
duration_sec: 83
---

# Distributed Transactions

> Source: [Distributed Transactions](https://youtube.com/watch?v=5wiJvT7EY3o)

## Summary

This video explains the challenges of handling transactions across multiple services in distributed systems, contrasting the traditional single-database approach with the complexities of distributed transactions. It introduces two primary solutions: the two-phase commit protocol and the saga pattern, highlighting their trade-offs and practical implications.

### Key Points

- **Single Database Transactions** [00:01] — In a single database, transactions provide all-or-nothing atomicity, ensuring that either all operations succeed together or none do.
- **Distributed Transaction Problem** [00:15] — At scale, services like inventory, payment, and shipping use separate databases, so a failure in one (e.g., shipping) after another succeeds (e.g., payment) creates inconsistency.
- **Two-Phase Commit** [00:29] — A coordinator asks all services if they can commit, then waits for unanimous agreement before committing. However, services are locked during the wait, and if the coordinator crashes, they remain stuck holding locks indefinitely.
- **Two-Phase Commit Drawbacks** [00:42] — Because of the locking and coordinator crash risk, almost nobody uses two-phase commit in production.
- **Saga Pattern** [00:56] — Instead of one atomic operation, each service performs its steps independently. If a later step fails, compensating actions undo earlier steps (e.g., refund payment, restock inventory).
- **Trade-offs of Sagas** [01:10] — Sagas avoid the coordinator bottleneck but introduce a window where the system is partially incomplete. Distributed systems don't get atomicity for free.

### Conclusion

Distributed transactions require choosing between the blocking risks of two-phase commit and the eventual consistency of the saga pattern, with the latter being the practical choice in most production systems.

## Transcript

handle transactions when an operation spans multiple services. this. When everything lives in a single database, it's really straightforward. all or nothing atomicity by transactions. Either every right
succeeds together or none of them do. But at scale, inventory, payment, and with separate databases. So, what if payment succeed, but the rights of a shipping database fails? You have two options. Option one is called a
two-phase commit. A coordinator asks every service, "Can you commit?" and then waits for all of them to say yes before anyone actually commits. The problem is that every service is locked and waiting. If the coordinator
crashes, they're all stuck holding locks forever. Almost nobody uses this in production for that reason. Option two is the saga pattern. Instead of one big atomic operation, each service does its own steps independently. If a later step
fails, you can run what's called a compensating action to undo for the earlier ones. Shipping fails, refund the payment, restock the inventory, etc. coordinator bottleneck. The trade-off is that there's a window where your system
is partially incomplete. But that's the real world. Distributed systems don't get atomicity for free. Learn more at hellointerview.com.