Architecture
Diagramme d'architecture saga de réservation de voyage orchestrant les réservations de vol, d'hôtel et de location de voiture comme une seule transaction distribuée, avec compensation automatique pour annuler toutes les réservations si une étape échoue. Ce modèle représente le cas d'usage classique de saga où plusieurs services indépendants doivent tous réussir ou tous annuler, garantissant que les voyageurs ne se retrouvent jamais avec des réservations partielles. Parfait pour démontrer les patterns saga avec un scénario métier réel.
Code FlowZap complet
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"]
}
Pourquoi ce 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.
Comment ça fonctionne
- 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 | Architecture Saga de réservation de voyage |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture saga par orchestration avec un orchestrateur central coordonnant des transactions distribuées multi-étapes à travers les services Commande, Inventaire et Paiement, avec une chaîne de compensation dédiée pour le rollback en cas d'échec. Ce modèle représente le pattern saga basé sur l'orchestration où un coordinateur unique gère le cycle de vie de la transaction et déclenche des actions compensatoires lorsqu'une étape échoue. Essentiel pour les architectes implémentant des transactions distribuées fiables sans commit en deux phases.
Architecture
Diagramme d'architecture saga par chorégraphie où les services Commande, Paiement et Inventaire se coordonnent par événements de domaine sans orchestrateur central, chaque service publiant et s'abonnant à des événements qui font avancer la transaction ou déclenchent la compensation. Ce modèle représente l'approche saga décentralisée où les services réagissent de manière autonome aux événements, réduisant les points de défaillance uniques au prix d'une complexité accrue dans le suivi de l'état de la saga. Idéal pour les équipes préférant l'autonomie des services au contrôle centralisé.
Architecture
Diagramme d'architecture saga d'exécution de commande avec quatre étapes séquentielles : vérification du client, réservation d'inventaire, autorisation de paiement et création d'expédition, avec une chaîne de compensation qui inverse les étapes complétées en cas d'échec. Ce modèle représente le cycle de vie complet de la commande sous forme de saga, montrant comment chaque service participe à la transaction et comment les actions compensatoires maintiennent la cohérence des données. Idéal pour les architectes e-commerce concevant des pipelines de traitement de commandes fiables.
Architecture
Diagramme d'architecture d'orchestration AWS Step Functions avec des workflows de machine à états incluant des états de choix, du traitement parallèle, des patterns d'attente de callback et un rollback de compensation pour les étapes échouées. Ce modèle représente l'orchestration de workflows serverless où des processus multi-étapes complexes sont définis comme des machines à états avec gestion des erreurs et logique de retry intégrées. Critique pour les équipes construisant des workflows serverless fiables nécessitant une approbation humaine ou des processus de longue durée.
Architecture
Diagramme d'architecture de transaction distribuée implémentant le protocole de commit en deux phases avec un coordinateur de transaction envoyant des messages de préparation et de commit aux services participants, avec un abandon global en cas d'échec de vote. Ce modèle visualise le protocole 2PC classique utilisé lorsqu'une cohérence forte est requise entre plusieurs services, montrant les phases de préparation, vote et commit/abandon. Important pour comprendre les compromis de consensus distribué dans les architectures microservices.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.