题目重点：SD 题目完整列出事件/批量两类及 Email、SMS、Push、Tweets 渠道；设计共享投递管线和不同安全/时效策略。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 真实渠道、发送权限、法律/隐私规则依地区和公司政策确认；文章只讨论系统设计，不推定实际 Airbnb 通知实现。
- 预订/入住事件由上游持久化后发布，通知服务允许至少一次事件输入，靠幂等发送记录避免明显重复。
- 门锁码属敏感内容，需要最小权限、到期控制和受控通道；不允许进入普通营销活动模板。
解题路线
- 定义通知请求契约：eventId/campaignId、recipient、templateVersion、locale、channel、priority、scheduledAt 和业务幂等键。
- 事件触发从可靠事件流摄取，批量从经授权的人群快照生成任务；两者汇入队列，但高优先级事务通知与营销分开限流和隔离。
- 投递 worker 在发送前核用户偏好、退订、静默时段、目标地址有效性及安全级别；门锁码在允许时间窗短时读取/生成，模板变量和日志需脱敏。
- 为每渠道提供 adapter、幂等/outbox、重试退避、供应商故障切换和 dead-letter；供应商调用超时进入 UNKNOWN，先查回执再决定是否重发。
- 批量作业分片、节流、暂停/取消，避免峰值压垮事务通知；记录模板版本、provider ID、发送/到达/打开等状态，明确哪些事件可观察。
- 监控端到端送达时延、重复率、失败/退订率、队列积压、成本和敏感信息访问；按预订邮件/门锁码/营销分别设 SLO。
手动走一遍
训练例：预订成功写 eventId=e1，事件重投两次，发送记录以 (e1,recipient,channel,template) 去重；入住当天 9:00 计划短信门锁码，若用户手机号无效则报警/人工流程，不能改发到营销 Push。批量活动排队时，e1 事务邮件仍有独立容量。
规模与取舍
事件通知写入量随业务事件数线性，批量发送随目标人群规模线性；峰值任务数、渠道 TPS、重试倍数与模板渲染成本决定 worker 容量。题目无 Airbnb 实际发送规模，不给虚构吞吐。
易错点与追问
容易失分的边界
- 把营销与门锁码放同一优先级/权限队列。
- 事件重投导致重复发送。
- 忽略用户偏好和退订。
- 供应商超时就立即换通道重发造成多次通知。
- 门锁码明文写入通用日志或长期缓存。
继续深挖
- 感兴趣 listing 从不可订变可订时如何触发并去重？
- 跨时区入住当天如何定时？
- 供应商回执延迟时如何判定成功？
- 大规模营销任务如何不影响预订确认？
