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.
Code FlowZap complet
OrderService { # Order Service
n1: circle label:"New Order Received"
n2: rectangle label:"Validate Order"
n3: rectangle label:"Emit OrderCreated Event"
n4: rectangle label:"Listen for PaymentConfirmed"
n5: rectangle label:"Update Order Status"
n6: circle label:"Order Complete"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Valid"]
n3.handle(bottom) -> EventBus.n7.handle(top) [label="Publish"]
n4.handle(right) -> n5.handle(left) [label="Confirmed"]
n5.handle(right) -> n6.handle(left)
}
EventBus { # Event Bus
n7: rectangle label:"OrderCreated Topic"
n8: rectangle label:"PaymentConfirmed Topic"
n9: rectangle label:"InventoryReserved Topic"
n10: rectangle label:"ShipmentScheduled Topic"
n7.handle(bottom) -> PaymentService.n11.handle(top) [label="Subscribe"]
n8.handle(top) -> OrderService.n4.handle(bottom) [label="Notify"]
n8.handle(bottom) -> InventoryService.n14.handle(top) [label="Subscribe"]
n9.handle(bottom) -> ShippingService.n17.handle(top) [label="Subscribe"]
}
PaymentService { # Payment Service
n11: rectangle label:"Receive OrderCreated"
n12: rectangle label:"Process Payment"
n13: rectangle label:"Emit PaymentConfirmed"
n11.handle(right) -> n12.handle(left) [label="Charge"]
n12.handle(right) -> n13.handle(left) [label="Success"]
n13.handle(top) -> EventBus.n8.handle(bottom) [label="Publish"]
}
InventoryService { # Inventory Service
n14: rectangle label:"Receive PaymentConfirmed"
n15: rectangle label:"Reserve Stock"
n16: rectangle label:"Emit InventoryReserved"
n14.handle(right) -> n15.handle(left) [label="Allocate"]
n15.handle(right) -> n16.handle(left) [label="Reserved"]
n16.handle(top) -> EventBus.n9.handle(bottom) [label="Publish"]
}
ShippingService { # Shipping Service
n17: rectangle label:"Receive InventoryReserved"
n18: rectangle label:"Schedule Shipment"
n19: rectangle label:"Emit ShipmentScheduled"
n17.handle(right) -> n18.handle(left) [label="Plan Route"]
n18.handle(right) -> n19.handle(left) [label="Scheduled"]
n19.handle(top) -> EventBus.n10.handle(bottom) [label="Publish"]
}
Pourquoi ce workflow ?
Centralized orchestrators become bottlenecks and single points of failure as the number of services grows. Event-driven choreography distributes coordination logic across services, where each service reacts autonomously to events—eliminating the need for a central coordinator and enabling truly independent service deployment.
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 and processes the payment.
- Step 3: On success, a PaymentConfirmed event is published to the event bus.
- Step 4: The Inventory Service reacts to PaymentConfirmed by reserving stock.
- Step 5: The Shipping Service reacts to InventoryReserved by scheduling shipment.
- Step 6: The Order Service listens for saga completion events to update the final order status.
Alternatives
Orchestration-based sagas provide better visibility but create a central coordinator dependency. Choreography is harder to debug but more resilient. This template helps teams understand the event flow in a choreographed system.
Key Facts
| Template Name | Architecture événementielle par chorégraphie |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
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.
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 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 Backend-for-Frontend avec des couches BFF séparées pour les clients web et mobile, chacune optimisant les réponses API pour sa plateforme spécifique tout en partageant des microservices backend communs. Ce modèle montre comment éviter les API universelles en adaptant l'agrégation des données et l'optimisation des charges utiles par type de client. Recommandé pour les équipes servant plusieurs plateformes frontend depuis un backend microservices partagé.
Architecture
Diagramme d'architecture événementielle publish-subscribe avec broker de messages Kafka ou RabbitMQ, sérialisation d'événements, partitionnement de topics, livraison fan-out vers plusieurs consommateurs et gestion des erreurs via file de lettres mortes. Ce modèle représente le pattern fondamental de messagerie asynchrone où producteurs et consommateurs sont entièrement découplés via un broker de messages. Essentiel pour les architectes construisant des systèmes événementiels faiblement couplés et évolutifs.
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.