基于Event Sourcing的系统如何获取指定日期的状态？

核心逻辑是用稀疏快照做锚点+隔离链路临时重放+热点数据预生成，既不违反架构规范直接查Write Model，也不会产生不可接受的存储开销，完全能满足业务查询需求。

具体落地步骤 #

• 首先构建稀疏快照锚点，放弃全时间点全量存储投影的思路
  按业务可接受的重放时长设置快照间隔：先压测单节点重放事件的性能，比如单节点每秒能重放1万条事件，业务要求历史查询响应时长不超过3s，那就把快照间隔设为重放2.5万条事件对应的时间周期（通常是1~4周，业务实体量大的场景可以按租户、业务域拆成细粒度分片快照，进一步降低单份快照的大小）。每份快照只需要存三个核心信息：快照生成时的全局事件版本号、快照生成时间戳、对应投影的全量状态数据。这种稀疏快照的存储开销只有按天全量存储方案的几十分之一，完全可控。
• 搭建隔离的历史查询临时投影链路，和线上实时读链路完全物理隔离
  收到指定历史时间点T的查询请求时，执行三步计算：
  1. 从快照存储中找到生成时间早于T、且离T最近的快照作为计算基底
  2. 从事件存储的只读副本中，拉取该快照对应事件版本之后、事件发生时间早于等于T的所有关联事件（提前给事件按实体ID、事件类型、时间维度建好二级索引，只拉取查询涉及的实体相关事件，不要扫全量事件）
  3. 在独立的临时计算上下文中重放拉取到的事件，叠加在快照基底上得到T时间点的准确状态，返回结果后直接销毁临时计算上下文，不做持久化。
     整个链路完全运行在Read侧，全程不触碰Write Model的写入链路，完全符合架构规范。
• 对高频查询的历史时间点做预生成持久化
  统计业务侧的历史查询热点，比如月末对账、年终统计需要的每月最后一天、每年最后一天的状态，直接在后台低峰期提前计算好这些固定时间点的投影，存在专门的历史投影库中，用户查询时直接命中返回，不需要临时重放。这类热点时间点的数量非常少，不会带来存储压力。
• 配套优化手段
  给历史查询链路加一层短周期缓存，比如同一个时间点的查询请求10分钟内重复发起，直接返回缓存结果，避免重复计算；对于超大查询范围的请求（比如查全平台一整年的历史状态），走异步导出队列，不要占用在线查询的资源，计算完成后通知用户取结果即可。

避坑提醒：不要为了省事儿直接开放Write Model的查询权限，一旦打破读写边界，后续Write Model的迭代会被读需求强绑定，完全失去CQRS架构读写分离的优势；也不要为了追求极致响应速度把快照间隔设的过小，先根据业务SLA算好可接受的最大重放窗口，再倒推快照间隔，存储成本和查询性能完全可以做到平衡。

内容的提问来源于stack exchange，提问作者Jose Alonso Monge