[00:01] 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
[00:15] 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
[00:29] 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
[00:42] 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
[00:56] 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
[01:10] is partially incomplete. But that's the real world. Distributed systems don't get atomicity for free. Learn more at hellointerview.com.