Distributed transactions

Your interviewer asks you how you'd handle transactions when an operation spans multiple services. Most candidates have never thought about this. When everything lives in a single database, it's really straightforward. This is because SQL databases guarantee all or nothing atomicity by transactions. Either every right succeeds together or none of them do. But at scale, inventory, payment, and shipping, they're all separate services 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. There's no locks and there's no 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.