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.
Code FlowZap complet
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"]
}
Pourquoi ce 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.
Comment ça fonctionne
- 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 | Architecture du pattern Saga par orchestration |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
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.
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.
patterns
Pattern d’orchestration Saga pour transactions distribuées entre les services Commande, Paiement et Expédition avec compensation et retour arrière automatiques en cas d’échec.
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.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.