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é.
Code FlowZap complet
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"]
}
Pourquoi ce 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.
Comment ça fonctionne
- 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 | Architecture du pattern Saga par chorégraphie |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture de chorégraphie événementielle où les microservices se coordonnent par événements sans orchestrateur central, avec les services Commande, Paiement, Inventaire et Expédition réagissant aux événements de domaine les uns des autres. Ce modèle représente le pattern de coordination décentralisée où chaque service ne connaît que ses propres responsabilités et publie des événements pour que d'autres les consomment. Idéal pour les équipes favorisant l'autonomie des services plutôt que le contrôle centralisé des workflows.
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 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 d'événements de domaine montrant comment les racines d'agrégat émettent des événements de domaine qui sont distribués à la fois en interne aux gestionnaires locaux et en externe aux consommateurs d'événements d'intégration dans d'autres contextes bornés. Ce modèle représente le pattern d'événements DDD où la logique de domaine déclenche des effets de bord via un dispatcher d'événements propre, maintenant la séparation entre les préoccupations de domaine et d'infrastructure. Clé pour les équipes implémentant le Domain-Driven Design avec intégration événementielle.
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.