事件驱动通知中心架构

Architecture

事件驱动通知中心架构图，展示多源事件摄取、基于模板的消息渲染、按用户偏好路由到邮件（SendGrid/SES）、推送（FCM）、短信（Twilio）和 Slack 渠道，以及交付跟踪和重试机制。该模板模拟将业务服务与交付基础设施解耦的集中式通知系统，支持用户控制偏好的多渠道通信。适合构建可扩展通知基础设施的平台团队。

下载 .fz 文件

完整 FlowZap 代码

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.

工作原理

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.

替代方案

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	事件驱动通知中心架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)