总览

设计一高可靠之通知系统，支持推送通知、短信及电子邮件，服务逾百万用户。此系统须保证：

• 无重复通知
• 无遗漏发送
• 于服务商故障时仍能优雅降级
• 具备可伸缩性与可观测性

高阶架构

Client/API
   ↓
Notification Service
   ↓
Message Queue (Kafka/SQS/RabbitMQ)
   ↓
Notification Workers
   ↓
Provider Adapters
(SendGrid, Twilio, Firebase, etc.)
   ↓
Webhook/Event Processor
   ↓
Notification Database + Audit Logs

核心组件

1. 通知API服务

处理：

• 通知之创建
• 验证
• 幂等性检查
• 消息排队

每请求得：

• 通知标识
• 幂等键

是也。服务储通知于处理前，以保其久存。

2. 消息队列

用 Kafka/SQS/RabbitMQ 以行异步之务。

其利有：

• 生消相离
• 纳流之峰
• 持重试之能
• 阻请之碍

信息永续，待其成功处理而存之。

3. 通知工者

专司者：

• 电子邮件
• 短信
• 推送之讯

责：

• 消受队列之讯
• 遣送通知
• 重试暂时之败
• 更新递送状态

工作者横向扩展

可靠性策略

不可变性

每条通知皆有：

• 唯一通知标识
• 不可变键

数据库约束：

UNIQUE(idempotency_key)

发送前：

• 工人察若警示已效
• 止复遣于重试

重试& 失败之理

失败之别：

• 暂时者 → 重试
• 永绝者 → 立即败

重试之策：

• 指数退避
• 死信队列（DLQ）
• 最大重试阈值

例如：

1 min → 5 min → 15 min → 1 hour

优雅降级

若提供者失效：

• 备用提供者自动激活

例如：

Twilio fails → switch to Termii
SendGrid fails → switch to SES

断路器可阻绝频呼不康之供者。

物送跟蹤

網鉤處理者得：

• 已達
• 未達
• 退回
• 開展之事件

諸事件悉儲於審計表。

資庫設計

表：

• 通知
• 投递尝试
• 提供者日志
• 模板
• 用户偏好

索引：

(user_id, created_at)
(status, channel)
(notification_id)

防止遗漏发送

为避免信息遗失：

• 存储于队列前之通知
• 采用事务性发件箱模式
• 调和之务，检视滞留之讯

例：

PENDING > 10 mins → requeue

可察之境

监察：

• 队列之深
• 供者之迟
• 重试之数
• 失达之率

器用：

• 普罗米修斯
• 格拉菲娜
• 云观测
• 信使

警报于异常失效峰值时触发

可扩展性

系统支持百万以上用户，其法有：

• 水平工作扩展
• 分区队列
• 无状态服务
• Redis缓存
• 適用時批處理

安全校備

• 加密供應者憑證
• 簽署網頁回呼
• 速率限制
• RBAC供管理員訪問
• 所有通知事件審計記錄

技術堆疊範例

• 後端：Node.js / Python
• 佇列：Kafka或SQS
• 資料庫：PostgreSQL
• 快取：Redis
• 提供者：Twilio(Firebase, SendGrid)
• 監控：Grafana + Prometheus
• 部署：Kubernetes/ECS