Consider a customer who clicks "Place Order" on an e-commerce site. Three things need to happen. The Inventory Service must reserve the items, the Payment Service must charge the customer's card, and the Order Service must create a record of the purchase. All three must succeed together, or none should happen at all.

What happens if the payment goes through, but the inventory update fails? You've just charged someone for a product you can't deliver. What if the order gets created, but the payment fails? You've promised goods without getting paid.

When all your data lives in a single database, solving this is usually straightforward. You wrap the changes in one transaction, and the database gives you atomicity. But the moment the state lives in multiple services, databases, or external systems, you have to coordinate independent components that can fail at different times. That is the world of distributed transactions.

This chapter covers why distributed transactions are so challenging, the different approaches engineers have developed to handle them, and how to choose the right approach for your system.