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.
Full FlowZap Code
OrderService { # Order Service
n1: circle label:"Place Order"
n2: rectangle label:"Create Pending Order"
n3: rectangle label:"Emit OrderCreated"
n4: rectangle label:"Listen for Saga Events"
n5: diamond label:"Saga Outcome?"
n6: rectangle label:"Confirm Order"
n7: rectangle label:"Cancel Order"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Pending"]
n3.handle(bottom) -> EventBus.n8.handle(top) [label="Publish"]
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="Success"]
n5.handle(bottom) -> n7.handle(top) [label="Failure"]
}
EventBus { # Event Bus
n8: rectangle label:"OrderCreated Topic"
n9: rectangle label:"PaymentProcessed Topic"
n10: rectangle label:"InventoryReserved Topic"
n11: rectangle label:"PaymentFailed Topic"
n8.handle(bottom) -> PaymentService.n12.handle(top) [label="Subscribe"]
n9.handle(bottom) -> InventoryService.n15.handle(top) [label="Subscribe"]
n10.handle(top) -> OrderService.n4.handle(bottom) [label="Notify Success"]
n11.handle(top) -> OrderService.n4.handle(bottom) [label="Notify Failure"]
}
PaymentService { # Payment Service
n12: rectangle label:"Process Payment"
n13: diamond label:"Payment OK?"
n14: rectangle label:"Emit PaymentProcessed"
n18: rectangle label:"Emit PaymentFailed"
n12.handle(right) -> n13.handle(left)
n13.handle(right) -> n14.handle(left) [label="Success"]
n13.handle(bottom) -> n18.handle(top) [label="Declined"]
n14.handle(top) -> EventBus.n9.handle(bottom) [label="Publish"]
n18.handle(top) -> EventBus.n11.handle(bottom) [label="Publish"]
}
InventoryService { # Inventory Service
n15: rectangle label:"Reserve Inventory"
n16: rectangle label:"Emit InventoryReserved"
n17: rectangle label:"Compensate: Release Stock"
n15.handle(right) -> n16.handle(left) [label="Reserved"]
n16.handle(top) -> EventBus.n10.handle(bottom) [label="Publish"]
n17.handle(top) -> EventBus.n11.handle(bottom) [label="On PaymentFailed"]
}
Why This Workflow?
Orchestration-based sagas create a central coordinator that becomes a single point of failure and a deployment bottleneck. Choreography distributes saga logic across participating services, where each service autonomously publishes and subscribes to events—enabling fully independent deployment and eliminating the coordinator dependency.
How It Works
- Step 1: The Order Service creates a pending order and publishes an OrderCreated event.
- Step 2: The Payment Service subscribes to OrderCreated, processes payment, and publishes PaymentProcessed or PaymentFailed.
- Step 3: The Inventory Service subscribes to PaymentProcessed and reserves stock.
- Step 4: On successful reservation, InventoryReserved is published, completing the saga.
- Step 5: If payment fails, PaymentFailed triggers compensation in the Inventory Service.
- Step 6: The Order Service listens for all outcome events to update the final order status.
Alternatives
Orchestration provides better visibility and easier debugging. Process managers offer a middle ground between pure choreography and orchestration. This template shows the fully decentralized choreography approach.
Key Facts
| Template Name | Saga Choreography Pattern Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control.
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.
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 domain events architecture diagram showing how aggregate roots raise domain events that are dispatched both in-process to local handlers and cross-boundary to integration event consumers in other bounded contexts. This template models the DDD event pattern where domain logic triggers side effects through a clean event dispatcher, maintaining separation between domain and infrastructure concerns. Key for teams implementing Domain-Driven Design with event-based integration.
Architecture
An AWS Step Functions orchestration architecture diagram with state machine workflows including choice states, parallel processing, wait-for-callback patterns, and compensation rollback for failed steps. This template models serverless workflow orchestration where complex multi-step processes are defined as state machines with built-in error handling and retry logic. Critical for teams building reliable serverless workflows that require human approval or long-running processes.
Architecture
A distributed transaction architecture diagram implementing the two-phase commit protocol with a transaction coordinator sending prepare and commit messages to participating services, with global abort on any vote failure. This template visualizes the classic 2PC protocol used when strong consistency is required across multiple services, showing the prepare, vote, and commit/abort phases. Important for understanding distributed consensus trade-offs in microservices architectures.