The Monolith "Easy Button"
In a monolithic application with a single relational database, keeping data consistent is straightforward. You wrap related operations in a database transaction, and the database engine guarantees that either all of them succeed together or none of them take effect. This is the foundation of reliable software.
Imagine an e-commerce "Checkout" action:
1. Create an Order record.
2. Decrement stock in the Inventory table.
3. Charge the user's credit card.
The database guarantees ACID properties — Atomicity (all or nothing), Consistency (data always moves from one valid state to another), Isolation (concurrent transactions don't interfere), and Durability (committed data survives crashes). Either all three steps happen perfectly, or none of them happen at all. You never end up with an order placed but stock not decremented.
The Microservices Reality
Now imagine you have split this into microservices:
- The OrderService has its own PostgreSQL database.
- The InventoryService has a completely separate MySQL database.
- The PaymentService is a third-party API (Stripe, Braintree, etc.).
A single database transaction cannot span across three different databases on three different servers. The ACID guarantee only applies within a single database engine's control. The moment you cross a network boundary, you are outside that safety net.
If the OrderService creates the order, calls the InventoryService to decrement stock, and then the InventoryService crashes mid-operation, your system is now in an inconsistent state: an order exists, but inventory was never updated. The customer paid for something the warehouse doesn't know to ship.
This is the core problem of Distributed Transactions: how do we guarantee data consistency when the data lives in multiple independent systems, each with their own storage, their own failure modes, and no shared transaction manager?