你会如何设计一个公司级的通知服务？

Question

你会如何设计一个公司级的通知服务？

IT Interview Practice · Accepted Answer

构建一个服务，让每个团队用**通知类型 + 收件人**来调用它，并由该服务来解析 channel、模板、用户偏好和优先级。关键的设计动作是**优先级车道（priority lanes）**——一个 OTP 不能排在面向 200 万用户的营销群发后面等待。

## 架构

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

## 组件与流程

- **Notify API** 接收一个带类型的请求：`{type: "otp", user, data}`。调用方从不选择 channel 或撰写文案——这些由服务负责，因此一次模板变更只需发布一次。
- **类型 → 策略**：每个**类型**映射到一个策略。*OTP* 是高优先级，SMS+Push，忽略营销退订，60 秒过期。*事务类（Transactional）*（收据、密码重置）是高优先级，遵守 channel 偏好。*营销类（Marketing）*是低优先级，走批量车道，严格遵守退订和免打扰时段（quiet hours）。
- **优先级车道**是带有独立 consumer group 的独立 Kafka topic。高优先车道几乎始终为空，能在毫秒内排空；批量车道可以积压数分钟而不影响 OTP 的 latency。这是最重要的单一决策。
- **偏好服务（Preference service）**针对每个收件人进行检查：是否退订？免打扰时段？按 channel 的开关？频率上限（frequency cap）？违反偏好的营销消息在这里被丢弃。
- **模板引擎（Template engine）**从带版本的模板 + 变量渲染本地化内容，使文案与代码解耦。
- **Channel 适配器**将 FCM/APNs、SendGrid、Twilio 包装在一个统一接口之后，每个都有自己的 rate limiter、重试和 DLQ（与任何批量发送者相同的扇出纪律）。

## 面试视角

面试官考察你是否分离**关注点（concerns）**：许多候选人构建一个直接发送邮件的单体，然后发现营销洪流会延迟 OTP。指出*优先级车道*、*偏好强制执行*和*幂等键（idempotency keys）*（使重试的请求不会重复通知）才是资深信号。"好"会增加 channel；"出色"会解释为什么 OTP 和营销绝不能共用一个队列，以及**回退链（fallback chain）**（Push 失败 → SMS）如何工作。

## 权衡与故障

- **一个服务与各团队各自实现**：集中化带来一致的偏好、限流和审计，但会成为关键依赖——它必须是高可用（HA）的，否则一次登录 OTP 中断会阻塞整个公司。
- **实时性与成本**：SMS 昂贵且慢；优先使用 Push/站内（In-App），仅对高价值类型回退到 SMS。
- **故障**：provider 中断触发回退链，而不是硬失败。**去重键（Dedup keys）**防止队列重投导致 OTP 发送两次。按类型跟踪投递 SLO——延迟的营销邮件没问题，延迟的 OTP 则是一次事故。

架构

组件与流程

面试视角

权衡与故障

相关问题