直接回答：分层架构：接入层（统一 API，鉴权、参数校验、模板渲染）→ 编排层（渠道路由策略、用户偏好与免打扰、频控）→ 发送层（每渠道独立 worker，对接 APNs/FCM/短信网关/邮件服务）→ 回执与重试（发送状态追踪、失败重投、死信）。队列是层间粘合剂：请求进 MQ 削峰，渠道间用不同队列隔离——短信通道堵塞不能拖死推送。
展开解析：关键设计点。模板与变量：模板版本化、多语言、变量渲染失败要兜底（退化为纯文本而非丢消息）。用户偏好是合规底线：退订、免打扰时段、按通知类别的订阅粒度，营销类必须可关。频控防骚扰：按用户聚合多业务的触达频率（全局每天最多 N 条营销），这需要跨业务的计数存储。优先级分级：验证码走独立高优通道，与营销队列物理隔离。可靠性语义：至少一次投递加业务幂等（用户收到重复推送的体验损失与丢通知的取舍按场景）；厂商通道（APNs 等）限流与 token 失效清理。可观测：按渠道的到达率、打开率、延迟分位，以及"投诉率"这个被低估的北极星。规模化时推送侧的 fan-out（千万级广播）要分片并行发送并支持灰度。
追问方向：广播场景的写扩散优化？如何做全链路 trace（从 API 到设备回执）？多供应商（短信双通道）的自动切换策略？
（约 460 字）