Saga Pattern

The Distributed Transaction Problem

Problem: How to maintain consistency across multiple services?

Traditional solution: 2PC (Two-Phase Commit) - but it’s:

• Blocking (locks resources)
• Doesn’t scale
• Single point of failure
• Not suitable for microservices

Learn More About 2PC

For a detailed explanation of 2PC (Two-Phase Commit), including how it works, its problems, and when it’s still used, see Distributed Transactions.

Solution: Saga Pattern - Sequence of local transactions with compensation!

---

What is Saga Pattern?

The Saga pattern is a distributed transaction management pattern that breaks a long-running transaction into a sequence of smaller, local transactions. Each local transaction commits independently, and if any step fails, the saga executes compensating transactions to undo the effects of previously completed steps.

The Core Concept

Unlike traditional ACID transactions that use two-phase commit (2PC) to ensure atomicity across services, sagas use eventual consistency. Each step in a saga is a local ACID transaction within a single service. If a step fails, instead of rolling back (which isn’t possible across services), the saga executes compensating actions in reverse order.

Key Insight: You can’t “rollback” a committed transaction in another service (the flight is already booked), but you can compensate (cancel the flight). Compensation is not the same as rollback - it’s a new business operation that undoes the effect of a previous operation.

Simple Analogy

Think of Saga like booking a trip:

1. Book flight (completed)
2. Book hotel (completed)
3. Book car (failed!)

Compensation:

• Cancel hotel
• Cancel flight

You can’t “rollback” (flight already booked), but you can compensate (cancel it).

Key Concepts

1. Local Transactions - Each step is ACID within its service
2. Compensation - Undo action for each step
3. Eventual Consistency - System eventually consistent
4. No Distributed Locks - Better scalability

---

Pattern 1: Orchestrator Saga

Central coordinator orchestrates all steps.

Characteristics:

• Centralized control - Easy to understand
• Easy to debug - All logic in one place
• Can retry - Orchestrator controls retries
• Single point of coordination - Can become bottleneck
• Tight coupling - Orchestrator knows all services

Orchestrator Implementation

---

Pattern 2: Choreography Saga

Distributed coordination. Each service knows next step.

Characteristics:

• Decoupled - Services don’t know about orchestrator
• Scalable - No single coordinator
• Flexible - Easy to add/remove services
• Hard to understand - Logic distributed
• Hard to debug - No central point
• No retry control - Each service handles retries

Choreography Implementation

---

Orchestrator vs Choreography

Aspect	Orchestrator	Choreography
Control	Centralized	Distributed
Complexity	Lower	Higher
Coupling	Higher	Lower
Debugging	Easier	Harder
Scalability	Lower	Higher
Use Case	Complex workflows	Simple workflows

Choose Orchestrator when:

• Complex workflow
• Need centralized control
• Need retry logic
• Easier debugging needed

Choose Choreography when:

• Simple workflow
• Need decoupling
• Need scalability
• Services are independent

---

Compensation Strategies

1. Compensating Action

Undo the action (if possible):

• Cancel order
• Release inventory
• Refund payment

2. Compensating Transaction

Opposite transaction:

• Add balance (compensates subtract balance)
• Release lock (compensates acquire lock)

3. TTL-Based Compensation

Automatic expiration:

• Reservation expires after timeout
• No explicit compensation needed

---

Key Takeaways

Saga Pattern

Sequence of local transactions with compensation. No distributed locks, better scalability.

Orchestrator

Central coordinator. Easier to understand and debug. Good for complex workflows.

Choreography

Distributed coordination. More decoupled and scalable. Good for simple workflows.

Compensation

Undo completed steps when saga fails. Not rollback, but compensating action. Critical for consistency.

---

Next Steps

• Master Idempotency - handling duplicate saga steps
• Review Event-Driven Architecture - sagas use events
• Understand Distributed Transactions - learn about 2PC and why sagas are needed