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.
Code FlowZap complet
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"]
}
Pourquoi ce 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.
Comment ça fonctionne
- 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 | Architecture Saga d'exécution de commande |
| 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 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 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.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.