事件存储（Event store）是否需具备ACID特性？原子性与事件不可变的矛盾探讨

术语明确 #

你提到的「存储事件的载体」，行业内统一称为Event Store，不用纠结和普通Database的术语差异，它是专门为事件溯源场景设计的存储系统。

Event Store的原子性实现 #

Event Store必须具备ACID中的原子性，但实现逻辑和你理解的「删除事件回滚」完全不同：

• 原子性的核心是事务内的事件批量写入要么全部成功持久化，要么全部失败不写入。比如你在一个业务操作中需要保存3个关联事件，只要其中任何一个写入失败，整个事务里的所有事件都不会被存储到Event Store中，从根源上避免了部分事件写入的不一致状态。
• 这完全符合事件溯源中「事件不可变」的原则，因为根本不会出现「写入后再删除」的操作，原子性是在写入前就保证的。

事件不可变前提下的状态修正 #

因为事件一旦写入就不能修改或删除，所以不能通过删除已保存事件来回滚状态。如果业务操作出错，正确的做法是：

• 添加补偿事件来修正状态。比如之前写入了「用户账户扣款100元」的事件，后续发现操作错误，不需要删除这个事件，而是新增一个「用户账户退款100元」的补偿事件，通过新事件抵消原事件的影响，同时完整保留操作的历史轨迹。

补偿操作是否需要手动执行？ #

不是所有场景都需要手动处理：

• 简单的业务错误可以通过预定义的自动补偿逻辑触发，比如当某个事件处理失败时，系统自动生成对应的补偿事件并写入Event Store。
• 复杂场景（比如涉及第三方系统的不可逆操作，如已完成的跨系统转账）可能需要人工介入确认后，再触发补偿事件的写入。

主流Event Store的实现逻辑 #

像EventStoreDB这类主流的Event Store，都严格遵循事件不可变的原则：

• 它们通过内置的事务机制保证批量事件写入的原子性，不会出现部分写入的情况。
• 所有事件一旦持久化就会被永久保留，状态的变更只能通过新增事件来实现，完整记录业务的全量操作历史。

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