Sagas and distributed transactions
How to keep data consistent when one business operation spans several services: why a single ACID transaction no longer works, two-phase commit and its problems, the saga pattern with compensating actions, choreography and orchestration, the outbox, idempotency, and designing for failure.
CodexBash, , 6 min read
In a single database, placing an order is easy to make safe: wrap the stock update, the payment record and the order row in one transaction, and they all commit or none do. Split the system into services, an order service, a payment service and an inventory service, each with its own database, and that guarantee disappears. There is no single transaction spanning three databases, yet the business still needs "order placed, payment taken, stock reserved" to be all or nothing. This article explains the two main answers: two-phase commit, and the far more common saga pattern.
Sign in to read the rest
The whole 6 minute article is free with an account, along with every problem, lesson and tutorial. No card.