Distributed Transactions: When One Business Action Spans Many Services

The payment gateway returned 200 OK. The customer’s card was charged ₹2,499. Then the inventory service — a different service, a different database — threw a 409 Conflict because the last unit sold out three milliseconds ago.

Now what? You can’t ROLLBACK. There is no transaction to roll back: the charge lives in the payments database, the failed reservation in the inventory database, and no COMMIT ever spanned the two. Your customer has paid for a phone you can’t ship, and the only thing standing between that and a chargeback is code you have to write on purpose. This is the entire problem of distributed transactions, and it has no clean answer — only a set of honest trades.

Why the easy answer is gone

Inside one relational database, “place order” would be four statements wrapped in BEGIN … COMMIT. The database gives you ACID: either all four land or none do, and no other transaction sees a half-written order. That guarantee is built on one write-ahead log, one lock manager, one clock.

Split those four statements across a payments service, an inventory service, and a shipping service — each owning its own database, which microservices demand — and every one of those shared foundations disappears. There is no common log, no lock you can hold across all three, no single authority that can say “commit everything.” Each service can only guarantee its own local transaction. Stitching those local commits into one business outcome is the job.

The members-only walkthrough picks up from here: Two-Phase Commit and why it blocks, the saga with its compensating transactions and the choreography-vs-orchestration split, the order saga in code, the dual-write trap and the transactional Outbox that closes it, the full 2PC-vs-saga tradeoff table, a worked interview problem, and a self-check quiz.