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.
Code FlowZap complet
Producer { # Event Producer
n1: circle label:"Business Action"
n2: rectangle label:"Create Domain Event"
n3: rectangle label:"Serialize Event"
n4: rectangle label:"Publish to Topic"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="OrderCreated"]
n3.handle(right) -> n4.handle(left) [label="Avro/JSON"]
n4.handle(bottom) -> Broker.n5.handle(top) [label="Produce"]
}
Broker { # Message Broker (Kafka/RabbitMQ)
n5: rectangle label:"Receive Event"
n6: rectangle label:"Partition by Key"
n7: rectangle label:"Persist to Log"
n8: rectangle label:"Fan-Out to Subscribers"
n9: rectangle label:"Dead Letter Queue"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Append"]
n7.handle(right) -> n8.handle(left) [label="Notify"]
n8.handle(bottom) -> Consumers.n10.handle(top) [label="Deliver"]
n9.handle(bottom) -> Consumers.n17.handle(top) [label="Failed Events"]
}
Consumers { # Event Consumers
n10: rectangle label:"Inventory Consumer"
n11: rectangle label:"Update Stock Level"
n12: rectangle label:"Notification Consumer"
n13: rectangle label:"Send Order Email"
n14: rectangle label:"Analytics Consumer"
n15: rectangle label:"Update Dashboard"
n16: diamond label:"Processing OK?"
n17: rectangle label:"Retry Handler"
n10.handle(right) -> n16.handle(left)
n16.handle(right) -> n11.handle(left) [label="Yes"]
n16.handle(bottom) -> n17.handle(top) [label="No"]
n17.handle(top) -> Broker.n9.handle(bottom) [label="DLQ"]
n12.handle(right) -> n13.handle(left) [label="Email"]
n14.handle(right) -> n15.handle(left) [label="Aggregate"]
}
Pourquoi ce workflow ?
Synchronous request-response communication between microservices creates tight coupling, cascading failures, and latency chains. The publish-subscribe pattern decouples producers from consumers through a message broker, enabling independent scaling, temporal decoupling, and resilient event processing with built-in retry mechanisms.
Comment ça fonctionne
- Step 1: A business action triggers the creation of a domain event in the producer service.
- Step 2: The event is serialized (Avro or JSON) and published to a topic on the message broker.
- Step 3: The broker partitions events by key for ordered processing and persists them to a log.
- Step 4: Multiple consumers subscribe to the topic and process events independently.
- Step 5: Failed events are routed to a dead letter queue after exceeding retry thresholds.
- Step 6: Operations teams monitor DLQ depth and investigate failed events through a dashboard.
Alternatives
Synchronous HTTP calls are simpler but create coupling. Point-to-point queues limit fan-out. Managed services like AWS SNS/SQS or Google Pub/Sub reduce operational overhead. This template visualizes the complete pub/sub lifecycle including error handling.
Key Facts
| Template Name | Architecture événementielle Publish-Subscribe |
| 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 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 de pipeline de streaming temps réel avec capteurs IoT, logs applicatifs et données de parcours utilisateur transitant par Kafka vers Apache Flink pour l'agrégation par fenêtre, la détection d'anomalies et la sortie multi-destinations vers des lacs de données et des tableaux de bord. Ce modèle visualise le traitement de flux de bout en bout, de l'ingestion à la transformation, au stockage et à l'alerte. Essentiel pour les ingénieurs data construisant des plateformes d'analyse et de surveillance en temps réel.
Architecture
Diagramme d'architecture de file de lettres mortes avec politiques de retry, backoff exponentiel, seuils de tentatives maximales, routage DLQ pour les messages échoués, alertes opérationnelles et workflows de retraitement manuel. Ce modèle représente le pattern critique de gestion des erreurs pour les systèmes de messagerie asynchrone, garantissant qu'aucun message n'est silencieusement perdu lors d'un échec de traitement. Essentiel pour construire des systèmes événementiels fiables avec des mécanismes de récupération appropriés.
Architecture
Diagramme d'architecture de composition d'API avec un service compositeur qui distribue des requêtes parallèles vers plusieurs microservices, collecte les réponses avec gestion de timeout et fusionne les résultats en une réponse unifiée unique avec support de repli partiel. Ce modèle représente le pattern de composition d'API utilisé lorsqu'une requête client unique nécessite des données de plusieurs services, évitant les appels directs de service à service. Utile pour les équipes construisant des couches d'agrégation dans les architectures microservices.
Architecture
Diagramme d'architecture de hub de notifications événementiel avec ingestion d'événements multi-sources, rendu de messages basé sur des templates, routage par préférences utilisateur vers les canaux email (SendGrid/SES), push (FCM), SMS (Twilio) et Slack, avec suivi de livraison et mécanismes de retry. Ce modèle représente un système de notifications centralisé qui découple les services métier de l'infrastructure de livraison, supportant la communication multicanal avec des préférences contrôlées par l'utilisateur. Idéal pour les équipes plateforme construisant une infrastructure de notifications évolutive.