The Distributed Transaction Problem

In the ShopEase monolith, placing an order was one @Transactional method: insert the order, reduce stock, record the payment. If anything failed, the database rolled everything back.

After the split, each service owns its own database (database per service). One business action now touches several databases that no single transaction can cover:

placeOrder()
     |
     +--> order-service      --> order_db      (INSERT orders)
     +--> inventory-service  --> inventory_db  (UPDATE stock)
     +--> payment-service    --> payment_db    (INSERT payments) + Razorpay API

 @Transactional only works inside ONE database connection.
 If payment fails AFTER stock was reduced, who puts the stock back?

Two-phase commit (XA transactions) asks every database to "prepare", then tells all of them to "commit". It gives strong consistency, but it is a poor fit for microservices:

• Blocking: rows stay locked while the coordinator waits for the slowest participant.
• Availability: if the coordinator or one service is down, nobody can commit.
• Limited support: Kafka, MongoDB, most cloud databases and every external API (Razorpay, Shiprocket) cannot join an XA transaction.
• Coupling: all services must be up at the same time for every order.

Microservices accept eventual consistency instead: each service commits its own local transaction, and the system reaches a consistent state a little later, using a Saga.

A Saga is a sequence of local transactions. Each step commits in its own service and triggers the next step. If a step fails, the saga runs compensating transactions that undo the earlier steps in reverse order.