事件该带「全量快照」还是只带「ID + 拉取」？一个吵了多年的经典分叉

背景

做异步事件链路，每个团队迟早要回答同一个问题：事件（event）到底带全量字段（fat event / fat payload），还是只带一个业务 ID，让下游自己去拉详情（thin event / thin payload）？

我在带团队设计订单、库存、支付这类事件的 topic schema 时，这个点几乎每次都吵。我先把两边（以及第三派）的论据摆一下，想听听大家真实场景下的取舍。

常见的几种立场

1. Fat 派：事件即契约，必须自包含、可重放、与生产方数据库解耦。如果生产方表结构变了，所有消费方跟着炸——用「fat event + schema 版本字段」是唯一解法。典型场景：Kafka → 数仓 / 审计流的 ETL 管道，下游根本不连生产方 DB，只能靠事件里的字段。
2. Thin 派：事件只是「变更通知」，真相源永远是 DB。fat event 有两个硬伤：一是快照不一致（T0 读库、T1 发消息，中间状态可能已变）；二是扇出冗余（1 个事件 → N 个消费组，N 份冗余字段，生产方加个字段要通知所有下游）。
3. 折中派：事件只带「下游做决策所需的最小字段集」，其余拉取。问题是「最小集合」怎么定，定小了下游拉，定大了又退回 fat。

我的倾向与理由

我倾向 thin 为主 + 明确的版本契约，理由有三：

• 真相源是 DB，事件里的快照永远是过期的，「事件即真相」是个幻觉，迟早被不一致咬一口；
• 扇出场景下（1 事件 → N 下游），fat 意味着 N 份冗余，thin 让每个下游只拉自己需要的列；
• 但我要认账：只读分析 / 审计 / 离线数仓这类不连生产方 DB 的下游，fat 更实际，这时我会单独出一条 fat 的 topic 给它们，而不是逼它们去拉。

想听大家

• 你们在什么场景选 fat、什么场景选 thin？有没有「生产方改了一个字段、N 个下游一起炸」的事故可以讲讲？
• 快照不一致（事件发出时 DB 状态已变）你们是怎么兜底的？是消费方拉取时以 DB 为准直接覆盖，还是带版本号做 CAS？
• 折中派的「最小字段集」你们是怎么定的？靠约定、靠 code review，还是有工具强制？

欢迎带具体的 topic 设计、字段清单、踩坑数据来聊，空对空的我怕聊不出东西。