事件溯源条目应存储事件负载还是视图模型更新内容？

不要在「存原始负载」和「存格式化后视图变更」里二选一，两类数据都要存，只是存储位置、承担的职责完全不同，这套设计是工业界踩了无数坑之后验证过的通用方案。

• 用于支持重放的核心事件流持久化层（比如Kafka、Pulsar的持久化Topic），必须存第三方推送的完整、未加工的原始请求负载，这是整个链路唯一的可信数据源。
  存的时候不要做任何业务层面的裁剪、转换，接收到的请求体是什么样就原样序列化存储，连字符编码都不要改，同时附带接收时间戳、第三方请求ID、签名校验结果这类基础元数据。哪怕原始负载里有大量你当前业务用不上的冗余字段也不要删——你永远不知道下个月会不会因为可视化加新维度、排查线上bug、合规审计需要用到这些字段。
  只要你存的是全量原始负载，后续不管格式化逻辑怎么迭代、之前的转换逻辑出了什么bug，你都能通过重放原始数据，用修正后的逻辑重新算出全量正确的视图数据，不会出现历史数据无法追溯的死局。
• 经格式化函数处理后的视图模型变更，不要存入核心重放事件流，按用途单独存到两类存储中：
  • 直接写入面向可视化场景优化的读模型存储（比如OLAP数据库、Elasticsearch、带索引的缓存等），作为预计算好的投影（Projection）对外提供查询能力，避免每次可视化请求临时做格式转换，把查询延迟压到最低。
  • 如果后续有基于视图变更触发内部业务流转的需求（比如数据异常告警、联动内部其他系统），可以单独发一个内部领域事件Topic，在这个Topic里存格式化后的视图变更事件即可。这类内部事件的持久化等级、留存周期可以按需设置，比如原始负载要存1-3年满足合规和重放要求，内部视图事件只存7天供下游消费即可，能省大量存储成本。

为什么不推荐只存单一类型数据 #

只存格式化后的视图变更：只要你的系统不是写完就再也不迭代（现实中不存在这类系统），就彻底失去了重算历史数据的能力。不少团队图省事只存处理后的数据，等过了几个月发现之前的格式化逻辑漏了枚举映射、算错了指标单位，所有历史数据全错，再找第三方补要历史日志，往往要付出极高的沟通、时间成本，甚至根本拿不到历史数据。
只存原始负载不存处理后的视图：每次查询、每次重放都要重新跑全量格式化逻辑，数据量上来之后可视化查询延迟根本扛不住；如果格式化逻辑依赖外部关联数据（比如第三方传的外部ID要映射为内部组织ID），重放时外部接口变更、历史关联数据被删除，会直接导致重放流程卡壳。

实操补充建议 #

• 原始负载在入口接收时就生成全局唯一的事件ID，后续所有衍生的视图变更、内部事件都要关联这个原始ID，出问题时可以顺着ID一路从最终展示的视图追溯到最原始的第三方请求，排查效率能提升数倍。
• 重放逻辑不要直接把原始事件丢给当前线上版本的格式化函数处理，要给格式化逻辑做版本标记，比如v1版本的格式化函数处理2024年3月之前的原始数据，v2版本处理之后的批次，重放时按接收时间路由到对应版本的处理逻辑，避免新老逻辑不兼容导致重放结果错误。
• 如果有合规要求不能留存原始敏感字段，就在接收入口先做独立的、版本化的不可逆脱敏，再存入原始事件流。脱敏逻辑不要和业务格式化逻辑混在一起，要能明确追溯每一批原始数据用的是哪版脱敏规则，避免合规风险。

内容的提问来源于stack exchange，提问作者Richard Miles