CQRS/ES架构下客户文档唯一性校验与补偿事件处理问询

我太懂这种感受了——CQRS/ES架构确实能带来不少优势，但偏偏会把CRUD里习以为常的唯一性校验这类常规问题，变成棘手的难题，核心就是那个绕不开的最终一致性特性。结合你描述的场景，我来梳理下当前方案的逻辑，再聊聊可以优化的方向：

问题背景 #

你正在开发一个基于CQRS/ES的单微服务项目，用EventStore作为事件存储。需求很明确：客户注册的REST API要求文档编号唯一，必须避免重复注册。但麻烦的是，哪怕是在同一个微服务里，命令端和查询端之间也存在最终一致性，这让传统的同步校验逻辑没法100%可靠。

当前解决方案梳理 #

你现在的思路是通过「双校验+补偿」来应对这个问题：

• 命令端预校验：在把CustomerCreated事件提交到EventStore之前，先去查询PostgreSQL侧的查询应用，确认没有重复的文档编号后，才允许提交事件。
• 查询端最终校验：查询应用处理事件并写入PostgreSQL时，再次执行文档编号的唯一性校验。
• 冲突补救：如果查询端发现重复，就拒绝该事件，同时发送补偿事件（比如CustomerMarkedAsDuplicate）来撤销/禁用这个重复的客户，还要终止EventStore中对应的客户事件流。

待优化的核心痛点 #

这个方案确实能跑通，但有两个地方可以进一步打磨：

1. 用户体验与补偿逻辑复杂度：用户提交注册请求后，可能立刻收到「注册成功」的响应，但后续却因为重复被悄悄禁用/撤销，这种延迟的不一致会让用户困惑，还得额外做通知机制、错误兜底，同时要保证补偿事件的可靠执行，整体复杂度很高。
2. 事件流终止的潜在风险：直接终止EventStore里的客户事件流，如果后续还有针对该客户的命令在流终止前发出，很容易触发异常；而且如果终止操作本身失败，会留下不一致的事件流状态。另外，补偿事件还得保证幂等性，避免重复执行带来的副作用。

内容的提问来源于stack exchange，提问作者Leonardo Ferreira