⚡ Event-Driven Architecture
🔄 Saga Transaction Machine Simulator
Visualize choreography Saga flows — success path and payment failure with rollback
Use the interactive simulator below to run both the happy path (all services succeed) and the failure path (payment fails, triggering compensating actions in reverse order). Watch how the system achieves eventual consistency without relying on a distributed ACID transaction.
Key Concepts
The Happy Path
Order is Created → Inventory is Reserved → Payment is Processed. Each service publishes an event that triggers the next service in the chain. If all succeed, the Saga completes successfully.
The Failure Path
If Payment fails (e.g. Insufficient Funds), the system cannot simply 'Rollback' the database because Inventory and Order are in different databases. Instead, it triggers Compensating Transactions.
Compensating Transactions
Payment Service publishes 'PaymentFailed'. Inventory Service consumes this and runs a transaction to Add Stock back. Order Service consumes it and marks the Order as 'Cancelled'.
Eventual Consistency
During a Saga, the system is briefly inconsistent (Order is 'Pending' while Payment is processing). But it guarantees Eventual Consistency — eventually, the order will either be fully confirmed or fully cancelled.
⚡ Interactive Architecture Simulator
Distributed Saga State Machine
1
Order ServiceCreate Order
→
2
Stock ServiceReserve Inventory
→
3
Payment ServiceCharge Customer
→
4
Notification ServiceSend Receipt
Saga Step Execution Latency & Flow Timeline
Step Latency (ms): 0
Active Microservice Step: 0
Timeout Limit (1000ms): 1000
20:06:31Saga Machine ready. Select mode & run flow.
How to use this Simulator
The Simulator below represents a Choreography-based Saga pattern across three separate microservices: Order, Inventory, and Payment. Because they use 'Database-per-service', there is no shared database to lock.
- **Run Success Flow:** Watch how events are passed sequentially. No central orchestrator is needed; each service just listens for the event it cares about.
- **Run Failure Flow:** See what happens when the final step (Payment) fails. Notice how the system automatically 'rewinds' by issuing compensating events to undo the previous steps.
💡
Senior Architect Insight: In a Saga, you must design for idempotency. Since network failures might cause the message broker to deliver the 'PaymentFailed' event twice, the Inventory Service must check if it already released the stock for this specific order before adding stock back again.