Backend Concepts Every Frontend Engineer Must Understand | Part 16: Distributed Transactions & The Saga Pattern

How Does a Transaction Succeed Across 4 Services Without a Shared Database?

In a traditional monolithic backend, handling an e-commerce order is straightforward:

BEGIN TRANSACTION;
  INSERT INTO orders ...;
  UPDATE inventory ...;
  INSERT INTO payments ...;
COMMIT;

If any step fails, the database automatically rolls back everything.

But what happens in a Microservices architecture where each service has its own completely isolated database?

• Order Service writes to its PostgreSQL database.
• Payment Service talks to Stripe.
• Inventory Service updates Redis.
• Shipping Service writes to MongoDB.

What happens if the payment succeeds, but the inventory check fails?

Enter the Saga Pattern & Compensating Transactions

Because you cannot run a single ACID transaction across distributed networks without extreme performance degradation, systems use the Saga Pattern:

• A sequence of localized transactions executed in order.
• If step 3 fails, the system executes Compensating Actions backward to undo previous steps (e.g., refund the payment and cancel the pending order).

Why This Matters for Frontend Engineers:

Because Sagas take time to settle, your API will often respond with an intermediate state (PENDING_VERIFICATION). Frontend engineers must design optimistic interfaces with progress steps rather than expecting instantaneous synchronous confirmation.