Architecture
A saga orchestration architecture diagram with a central orchestrator coordinating multi-step distributed transactions across Order, Inventory, and Payment services, with a dedicated compensation chain for rollback on failure. This template models the orchestration-based saga pattern where a single coordinator manages the transaction lifecycle and triggers compensating actions when any step fails. Essential for architects implementing reliable distributed transactions without two-phase commit.
Full FlowZap Code
Orchestrator { # Saga Orchestrator
n1: circle label:"Start Saga"
n2: rectangle label:"Create Saga Instance"
n3: rectangle label:"Execute Step 1: Create Order"
n4: rectangle label:"Execute Step 2: Reserve Inventory"
n5: rectangle label:"Execute Step 3: Process Payment"
n6: diamond label:"All Steps Succeeded?"
n7: rectangle label:"Mark Saga Complete"
n8: rectangle label:"Begin Compensation"
n9: circle label:"Saga Finished"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Initialize"]
n3.handle(right) -> n4.handle(left) [label="Step 1 OK"]
n4.handle(right) -> n5.handle(left) [label="Step 2 OK"]
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Yes"]
n6.handle(bottom) -> n8.handle(top) [label="No"]
n7.handle(right) -> n9.handle(left)
n8.handle(bottom) -> Compensation.n16.handle(top) [label="Rollback"]
n3.handle(bottom) -> OrderService.n10.handle(top) [label="Command"]
n4.handle(bottom) -> InventoryService.n12.handle(top) [label="Command"]
n5.handle(bottom) -> PaymentService.n14.handle(top) [label="Command"]
}
OrderService { # Order Service
n10: rectangle label:"Create Order Record"
n11: rectangle label:"Return Order ID"
n10.handle(right) -> n11.handle(left) [label="Persisted"]
n11.handle(top) -> Orchestrator.n4.handle(bottom) [label="Success"]
}
InventoryService { # Inventory Service
n12: rectangle label:"Reserve Stock Items"
n13: rectangle label:"Return Reservation ID"
n12.handle(right) -> n13.handle(left) [label="Reserved"]
n13.handle(top) -> Orchestrator.n5.handle(bottom) [label="Success"]
}
PaymentService { # Payment Service
n14: rectangle label:"Charge Payment Method"
n15: rectangle label:"Return Transaction ID"
n14.handle(right) -> n15.handle(left) [label="Charged"]
n15.handle(top) -> Orchestrator.n6.handle(bottom) [label="Result"]
}
Compensation { # Compensation Steps
n16: rectangle label:"Reverse Payment"
n17: rectangle label:"Release Inventory"
n18: rectangle label:"Cancel Order"
n19: circle label:"Saga Rolled Back"
n16.handle(right) -> n17.handle(left) [label="Refund"]
n17.handle(right) -> n18.handle(left) [label="Unreserve"]
n18.handle(right) -> n19.handle(left) [label="Cancelled"]
}
Why This Workflow?
Distributed transactions across microservices cannot use traditional ACID transactions because each service owns its own database. The saga orchestration pattern uses a central coordinator to manage the transaction lifecycle, executing steps sequentially and triggering compensating actions when any step fails.
How It Works
- Step 1: The saga orchestrator creates a new saga instance and begins executing steps.
- Step 2: Step 1: The Order Service creates an order record and returns the order ID.
- Step 3: Step 2: The Inventory Service reserves stock items for the order.
- Step 4: Step 3: The Payment Service charges the customer payment method.
- Step 5: If all steps succeed, the saga is marked complete.
- Step 6: If any step fails, the compensation chain reverses all previously completed steps in reverse order.
Alternatives
Two-phase commit provides strong consistency but blocks resources and does not scale. Choreography-based sagas avoid the central coordinator but are harder to monitor. This template shows the orchestration approach with explicit compensation.
Key Facts
| Template Name | Saga Orchestration Pattern Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A travel booking saga architecture diagram orchestrating flight, hotel, and car rental reservations as a single distributed transaction, with automatic compensation to cancel all bookings if any reservation step fails. This template models the classic saga use case where multiple independent services must either all succeed or all roll back, ensuring travelers never end up with partial bookings. Perfect for demonstrating saga patterns with a real-world business scenario.
Architecture
A saga choreography architecture diagram where Order, Payment, and Inventory services coordinate through domain events without a central orchestrator, with each service publishing and subscribing to events that drive the transaction forward or trigger compensation. This template models the decentralized saga approach where services autonomously react to events, reducing single points of failure at the cost of increased complexity in tracking saga state. Best for teams preferring service autonomy over centralized control.
Architecture
An order fulfillment saga architecture diagram with four sequential steps: customer verification, inventory reservation, payment authorization, and shipment creation, with a compensation chain that reverses completed steps on failure. This template models the end-to-end order lifecycle as a saga, showing how each service participates in the transaction and how compensating actions maintain data consistency. Ideal for e-commerce architects designing reliable order processing pipelines.
patterns
Saga orchestration pattern for distributed transactions across Order, Payment, and Shipping services with automatic compensation rollback on failures.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.