Architecture
An event-driven notification hub architecture diagram with multi-source event ingestion, template-based message rendering, user preference routing across email (SendGrid/SES), push (FCM), SMS (Twilio), and Slack channels, with delivery tracking and retry mechanisms. This template models a centralized notification system that decouples business services from delivery infrastructure, supporting multi-channel communication with user-controlled preferences. Ideal for platform teams building scalable notification infrastructure.
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"]
}
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.
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.
| Template Name | Event-Driven Notification Hub Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
An event-driven publish-subscribe architecture diagram with Kafka or RabbitMQ message broker, event serialization, topic partitioning, fan-out delivery to multiple consumers, and dead letter queue error handling. This template models the foundational async messaging pattern where producers and consumers are fully decoupled through a message broker. Essential for architects building loosely coupled, scalable event-driven systems.
Architecture
An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.