Why Distributed Transactions Are a Problem?

In microservices:

• Each service has its own database

• Traditional 2PC (XA transactions) don’t scale well

• High latency & tight coupling

👉 So we use Saga Pattern.

🔹 What is Saga Pattern?

A Saga is a sequence of local transactions, where:

• Each service performs its transaction

• If one fails → compensating actions undo previous steps

🔹 Types of Saga

1️⃣ Choreography-based Saga

• No central controller

• Services react to events

📌 Example:

2️⃣ Orchestration-based Saga

• Central orchestrator controls flow

• Services respond to commands

📌 Example:

🔹 Example Flow (E-commerce)

1. Order Service → create order

2. Payment Service → deduct money

3. Inventory Service → reduce stock

❌ If inventory fails:

• Payment Service → refund

• Order Service → cancel order

🔹 Eventual Consistency

• Data is not consistent immediately

• Becomes consistent over time

🔹 Saga vs 2PC

🔹 Implementation Tools

• Kafka / RabbitMQ

• Spring State Machine

• Temporal

• Camunda

🔹 Real-World Use Case

💳 Payment success
📦 Inventory failure
↩ Refund triggered automatically

⭐ Interview One-Liner

“Saga handles distributed transactions by breaking them into local transactions with compensating actions.”

🔹 Follow-Up Questions Interviewers Ask

• Saga vs Eventual Consistency?

• How do you handle duplicate events?

• How do you ensure idempotency?