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
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é.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.