# 面向产品后端的事件驱动设计

若把事件当作契约而非消防水管，事件能帮助产品扩展工作流。

Published: 2024-07-24

## 发出关于业务的事实

有用的事件描述已发生的有意义之事：订单已下、录制已处理、会员已升级。它们不是数据库行的倾倒，也不是伪装的远程过程调用。用过去时命名事件，并包含足够上下文，使消费者无需喋喋不休的回调即可行动。

为载荷做版本。消费者按不同节奏演进，破坏性字段重命名可能在团队间级联成静默失败。

## 有意隔离消费者

每个消费者应拥有特定结果：发邮件、更新搜索索引、开通权益或通知分析。为不相关副作用共享一个巨型 worker，会重造带有更差失败模式的单体。

背压、重试与死信队列应按消费者归属。通知中的毒消息不应阻塞搜索索引。

- 默认让处理程序幂等
- 优先至少一次投递并配合去重键
- 诚实地文档化顺序保证
- 跨发布与消费追踪生产流

## 接受一致性权衡

事件驱动系统常拥抱最终一致性。产品文案与 UI 必须承认某些状态会异步追上。展示处理中状态，好过假装每个副作用都是瞬时的。

在需要强一致性之处——余额、库存预留、唯一约束——将该逻辑保留在事务边界内，并在提交后发出事件。

## 运营编排

没有关联 ID、滞后指标与重放工具，事件系统会变得神秘。构建在修复缺陷后安全重处理一段事件窗口的能力。将消费者滞后衡量为面向用户的可靠性信号。

当团队能通过添加消费者扩展产品行为、而不动摇核心事务路径时，事件驱动设计才划算。