Distributed Systems Visualization

Mastering the Saga Pattern

How to manage distributed transactions and data consistency in microservices without locking the world.

What is a Saga?

A Saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga.

If a local transaction fails because it violates a business rule, the saga executes compensating transactions that undo the changes that were made by the preceding local transactions.

lightbulb Why do we need it?

In monolithic apps, we use ACID transactions (commit/rollback). In microservices, a single transaction can't span multiple databases easily. link Sagas provide a way to maintain data consistency across services without the performance hit of global locking (like 2PC).

Monolith vs Microservices Data

Visualizing the shift from ACID to BASE consistency

Interactive Demo

The Saga Simulator: "Holiday Booking"

See how a Saga handles success and failure. Watch the "Compensating Transactions" (Rollbacks) in action when a step fails.

Scenario:

Mode:
hub Orchestrator
flight

Flight Service

Idle
Tx: Book Comp: Cancel
hotel

Hotel Service

Idle
Tx: Reserve Comp: Release
directions_car

Car Service

Idle
Tx: Rent Comp: Cancel

System Event Log

Ready
[7:09:54] System Ready.

Two Ways to Coordinate

Orchestration

Orchestration

A central coordinator (The "Conductor") tells participants what local transactions to execute.

  • check_circle Easier to understand the flow (centralized).
  • check_circle Great for complex workflows.
  • cancel The Orchestrator can become a "God Service".
Best for: Complex, enterprise workflows.
Choreography

Choreography

Decentralized. Each service produces and listens to events, deciding action independently.

  • check_circle Loose coupling; no central bottleneck.
  • check_circle Natural fit for event-driven architecture.
  • cancel Harder to visualize the global state (cyclic dependencies risk).
Best for: Simpler flows, highly decoupled teams.

Saga vs. Two-Phase Commit (2PC)

Feature
Two-Phase Commit (2PC)
Saga Pattern
Consistency
Strong (ACID)
Eventual (BASE)
Locking
Locks resources across services
No global locks
Rollback
Automatic (Transaction Manager)
Manual (Compensating Transactions)
Scalability
Low (Blocking)
High (Async/Non-blocking)
link Source: Baeldung - 2PC vs Saga