/System Design /Distributed Transactions ← All Designs
🔄

Distributed Transactions

Maintain consistency across services with the Saga pattern

Saga Pattern BASE
🎮 What you can do
  • Switch pattern: Choreography vs Orchestration
  • Pick a scenario and choose which step to fail
  • Click Run Saga or enable Auto-run
👁 What to watch
  • Steps light up green in sequence on success
  • Failure triggers amber compensating transactions running backwards
  • Event log shows every forward and rollback event in order
Pattern
Scenario
Fail at Step
Speed
Controls
Repeat with 2s delay
0
Completed
0
Rolled Back
0
Compensations
—
Avg Duration
Orchestration
Central coordinator drives the saga flow.
✓ Easy to monitor
✓ Clear audit trail
✗ Coordinator is SPOF
Event Log
saga.initialized
⚖️
Saga vs 2PC (Two-Phase Commit)
2PC
Coordinator asks all participants to "prepare" then "commit". Gives ACID but blocks on coordinator crash. Tight coupling. Poor availability.
Saga
Gives BASE — better availability. Uses compensating transactions instead of rollback. Eventual consistency. Works across service boundaries.
When to Use
Multi-service operations — e-commerce checkout, travel booking, bank transfers — where 2PC would be too slow or impossible across service boundaries.
Trade-offs
Eventual consistency. Compensations may fail too — need idempotency keys. Harder to debug. Need distributed tracing for observability.
Interview Tip
2PC gives ACID but blocks on coordinator crash. Saga gives BASE — better availability, but compensations instead of rollbacks. Always mention idempotency.