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.
Full FlowZap Code
OrderSaga { # Order Fulfillment Saga
n1: circle label:"Order Received"
n2: rectangle label:"Validate Order"
n3: rectangle label:"Step 1: Verify Customer"
n4: rectangle label:"Step 2: Check Inventory"
n5: rectangle label:"Step 3: Authorize Payment"
n6: rectangle label:"Step 4: Ship Order"
n7: diamond label:"Saga Complete?"
n8: rectangle label:"Finalize Order"
n9: rectangle label:"Trigger Compensation Chain"
n10: circle label:"Order Fulfilled"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Valid"]
n3.handle(right) -> n4.handle(left) [label="Verified"]
n4.handle(right) -> n5.handle(left) [label="In Stock"]
n5.handle(right) -> n6.handle(left) [label="Authorized"]
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left) [label="Success"]
n7.handle(bottom) -> n9.handle(top) [label="Failure"]
n8.handle(right) -> n10.handle(left)
n3.handle(bottom) -> Services.n11.handle(top) [label="Verify"]
n4.handle(bottom) -> Services.n12.handle(top) [label="Reserve"]
n5.handle(bottom) -> Services.n13.handle(top) [label="Charge"]
n6.handle(bottom) -> Services.n14.handle(top) [label="Ship"]
}
Services { # Participating Services
n11: rectangle label:"Customer Service"
n12: rectangle label:"Inventory Service"
n13: rectangle label:"Payment Service"
n14: rectangle label:"Shipping Service"
n11.handle(top) -> OrderSaga.n4.handle(bottom) [label="Customer OK"]
n12.handle(top) -> OrderSaga.n5.handle(bottom) [label="Reserved"]
n13.handle(top) -> OrderSaga.n6.handle(bottom) [label="Charged"]
n14.handle(top) -> OrderSaga.n7.handle(bottom) [label="Shipped"]
}
Compensations { # Compensation Actions
n15: rectangle label:"Reverse Payment"
n16: rectangle label:"Release Inventory"
n17: rectangle label:"Notify Customer"
n18: circle label:"Saga Rolled Back"
n15.handle(right) -> n16.handle(left) [label="Refund"]
n16.handle(right) -> n17.handle(left) [label="Unreserve"]
n17.handle(right) -> n18.handle(left) [label="Apology Email"]
n9.handle(bottom) -> Compensations.n15.handle(top) [label="Compensate"]
}
Why This Workflow?
E-commerce order fulfillment spans customer verification, inventory management, payment processing, and shipping—each owned by a different service. A saga ensures the entire fulfillment pipeline either completes successfully or rolls back cleanly, preventing scenarios like charging customers for out-of-stock items.
How It Works
- Step 1: The order is validated and the fulfillment saga begins.
- Step 2: Step 1: Customer Service verifies the customer account and shipping address.
- Step 3: Step 2: Inventory Service checks stock availability and reserves items.
- Step 4: Step 3: Payment Service authorizes and captures the payment.
- Step 5: Step 4: Shipping Service creates a shipment and generates tracking.
- Step 6: On failure at any step, the compensation chain reverses payment, releases inventory, and notifies the customer.
Alternatives
Synchronous orchestration with rollback is simpler but creates long-running transactions. Event-driven choreography distributes the logic but is harder to debug. This template shows the orchestrated saga approach for order fulfillment.
Key Facts
| Template Name | Saga Order Fulfillment Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
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 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
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.
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 service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.