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.
Full FlowZap Code
BookingAPI { # Booking API
n1: circle label:"Book Travel Package"
n2: rectangle label:"Validate Booking Request"
n3: rectangle label:"Start Booking Saga"
n4: rectangle label:"Return Booking Status"
n5: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Valid"]
n3.handle(bottom) -> Saga.n6.handle(top) [label="Execute"]
n4.handle(right) -> n5.handle(left)
}
Saga { # Saga Orchestrator
n6: rectangle label:"Step 1: Book Flight"
n7: rectangle label:"Step 2: Book Hotel"
n8: rectangle label:"Step 3: Book Car Rental"
n9: diamond label:"All Bookings OK?"
n10: rectangle label:"Confirm All Reservations"
n11: rectangle label:"Compensate Failed Steps"
n6.handle(right) -> n7.handle(left) [label="Flight OK"]
n7.handle(right) -> n8.handle(left) [label="Hotel OK"]
n8.handle(right) -> n9.handle(left)
n9.handle(right) -> n10.handle(left) [label="All Success"]
n9.handle(bottom) -> n11.handle(top) [label="Any Failed"]
n10.handle(top) -> BookingAPI.n4.handle(bottom) [label="Confirmed"]
n11.handle(top) -> BookingAPI.n4.handle(bottom) [label="Cancelled"]
n6.handle(bottom) -> FlightService.n12.handle(top) [label="Reserve"]
n7.handle(bottom) -> HotelService.n14.handle(top) [label="Reserve"]
n8.handle(bottom) -> CarService.n16.handle(top) [label="Reserve"]
}
FlightService { # Flight Service
n12: rectangle label:"Reserve Flight Seat"
n13: rectangle label:"Cancel Flight (Compensate)"
n12.handle(top) -> Saga.n7.handle(bottom) [label="Reservation ID"]
n13.handle(top) -> Saga.n11.handle(bottom) [label="Cancelled"]
}
HotelService { # Hotel Service
n14: rectangle label:"Reserve Hotel Room"
n15: rectangle label:"Cancel Hotel (Compensate)"
n14.handle(top) -> Saga.n8.handle(bottom) [label="Reservation ID"]
n15.handle(top) -> Saga.n11.handle(bottom) [label="Cancelled"]
}
CarService { # Car Rental Service
n16: rectangle label:"Reserve Car"
n17: rectangle label:"Cancel Car (Compensate)"
n16.handle(top) -> Saga.n9.handle(bottom) [label="Reservation ID"]
n17.handle(top) -> Saga.n11.handle(bottom) [label="Cancelled"]
}
Why This Workflow?
Travel bookings involve multiple independent services (flights, hotels, car rentals) that must either all succeed or all be cancelled—a partial booking is worse than no booking. The saga pattern ensures atomicity across these services without distributed transactions, with automatic compensation for failed steps.
How It Works
- Step 1: The booking API validates the travel package request and starts the saga.
- Step 2: Step 1: The Flight Service reserves a seat on the requested flight.
- Step 3: Step 2: The Hotel Service reserves a room for the travel dates.
- Step 4: Step 3: The Car Rental Service reserves a vehicle at the destination.
- Step 5: If all reservations succeed, all are confirmed simultaneously.
- Step 6: If any reservation fails, compensation actions cancel all previously made reservations.
Alternatives
Manual booking with separate confirmations risks partial bookings. Travel aggregators handle this internally but charge commissions. This template demonstrates the saga pattern with the classic travel booking use case.
Key Facts
| Template Name | Saga Travel Booking 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 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.
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.
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.