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.
Code FlowZap complet
Sources { # Event Sources
n1: rectangle label:"Order Service Event"
n2: rectangle label:"User Service Event"
n3: rectangle label:"Payment Service Event"
n4: rectangle label:"System Alert Event"
n1.handle(bottom) -> Hub.n5.handle(top) [label="OrderShipped"]
n2.handle(bottom) -> Hub.n5.handle(top) [label="AccountCreated"]
n3.handle(bottom) -> Hub.n5.handle(top) [label="PaymentFailed"]
n4.handle(bottom) -> Hub.n5.handle(top) [label="SystemDown"]
}
Hub { # Notification Hub
n5: rectangle label:"Receive Event"
n6: rectangle label:"Resolve Notification Template"
n7: rectangle label:"Check User Preferences"
n8: diamond label:"Channel Preference?"
n9: rectangle label:"Route to Email Channel"
n10: rectangle label:"Route to Push Channel"
n11: rectangle label:"Route to SMS Channel"
n12: rectangle label:"Route to Slack Channel"
n5.handle(right) -> n6.handle(left) [label="Match Template"]
n6.handle(right) -> n7.handle(left) [label="Render"]
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Email"]
n8.handle(bottom) -> n10.handle(top) [label="Push"]
n8.handle(left) -> n11.handle(right) [label="SMS"]
n8.handle(bottom) -> n12.handle(top) [label="Slack"]
n9.handle(bottom) -> Delivery.n13.handle(top) [label="Send"]
n10.handle(bottom) -> Delivery.n14.handle(top) [label="Send"]
n11.handle(bottom) -> Delivery.n15.handle(top) [label="Send"]
n12.handle(bottom) -> Delivery.n16.handle(top) [label="Send"]
}
Delivery { # Delivery Providers
n13: rectangle label:"SendGrid / SES"
n14: rectangle label:"Firebase Cloud Messaging"
n15: rectangle label:"Twilio SMS"
n16: rectangle label:"Slack Webhook"
n17: rectangle label:"Delivery Status Tracker"
n18: diamond label:"Delivered?"
n19: rectangle label:"Log Success"
n20: rectangle label:"Retry or DLQ"
n13.handle(right) -> n17.handle(left) [label="Callback"]
n14.handle(right) -> n17.handle(left) [label="Callback"]
n15.handle(right) -> n17.handle(left) [label="Callback"]
n16.handle(right) -> n17.handle(left) [label="Callback"]
n17.handle(right) -> n18.handle(left)
n18.handle(right) -> n19.handle(left) [label="Yes"]
n18.handle(bottom) -> n20.handle(top) [label="No"]
}
Pourquoi ce workflow ?
When every microservice implements its own notification logic, you get inconsistent messaging, duplicated delivery infrastructure, and no centralized preference management. A notification hub centralizes all outbound communication, routing events to the right channel based on user preferences while providing unified delivery tracking and retry mechanisms.
Comment ça fonctionne
- Step 1: Business services publish domain events (OrderShipped, PaymentFailed, AccountCreated) to the hub.
- Step 2: The hub resolves the appropriate notification template for each event type.
- Step 3: User channel preferences are checked to determine delivery method (email, push, SMS, Slack).
- Step 4: Messages are routed to the appropriate delivery provider (SendGrid, FCM, Twilio, Slack webhook).
- Step 5: Delivery status callbacks track whether each message was successfully delivered.
- Step 6: Failed deliveries are retried with backoff or routed to a dead letter queue for investigation.
Alternatives
Per-service notification logic creates inconsistency and duplication. Managed services like AWS SNS or Firebase handle delivery but not template management. This template shows the centralized notification hub with multi-channel routing.
Key Facts
| Template Name | Architecture de hub de notifications événementiel |
| 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 é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 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
Une architecture IA agentique event-driven qui remplace l'orchestrateur central par des topics Kafka/PubSub : les agents s'abonnent, réagissent et publient de nouveaux événements. Cela aligne les systèmes multi-agents avec la chorégraphie microservices éprouvée et est idéale pour les systèmes temps réel, haut débit et les configurations 'maillage d'agents'.
Architecture
Une architecture maillage d'agents event-driven utilisant un broker d'événements style Kafka. Plusieurs agents s'abonnent à des topics (commandes, alertes, analytique), traitent les événements indépendamment, et publient les résultats sur le bus. Idéal pour le traitement d'événements temps réel et architectures de services découplés.
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.