1. Distributed transactions

A customer clicks "Place order," sees a charge of $80 on their card, and then finds no order in their account. Nothing crashed loudly. The Payment service recorded the charge, and the Order service was supposed to record the order, but the process died between the two writes.

A distributed transaction is one business operation whose writes land in more than one service or database, so no single local transaction covers them. This tutorial is about the techniques that get such an operation to a consistent end state when it fails partway through.

It comes up in almost any microservice prompt that involves orders, payments, bookings, or transfers. The moment you draw an Order service, a Payment service, and Kafka, the interviewer asks what happens if payment succeeds and the next step fails, or what happens if you save the order and crash before publishing the event. At mid-level, spotting that crash window and naming the fix is usually enough. Senior candidates are expected to walk the mechanics: why two-phase commit blocks, how an outbox gets an event out safely, and how a saga undoes a charge.

We will use one example throughout: an online store's checkout, with an Order service on PostgreSQL, a Payment service, an Inventory service, and Kafka carrying events between them. By the end, you can look at a new cross-service write, point to the crash window, reject or justify two-phase commit, add an outbox where a database write must produce an event, and sketch a saga with compensating steps in a sensible order.