构建事件溯源系统时设计事件存储：选型、追加式持久化…

在构建事件溯源基础设施、选择事件存储技术或实现事件持久化模式时使用。

适用场景

解决思路

1. 按 stream 组织事件：每个 stream 对应一个 aggregate，stream 内按顺序保存事件，并维护全局位置（global position）实现全局有序。
2. 确保事件存储为 append-only：事件不可变，只允许追加。
3. 保证有序性：同时提供每个 stream 内排序和全局排序。
4. 实现版本化：使用版本号配合乐观并发控制。
5. 实现订阅：支持实时事件通知。
6. 实现幂等：安全处理重复写入。
7. 技术选型——纯事件溯源：选择 EventStoreDB。
8. 技术选型——已有 PostgreSQL 栈：选择 PostgreSQL，并手动实现事件存储逻辑。
9. 技术选型——高吞吐流处理：选择 Kafka，但注意它不适合 per-stream 查询。
10. 技术选型——Serverless、AWS-native：选择 DynamoDB，但注意查询限制。
11. 技术选型——.NET 生态：选择 Marten。
12. 需要具体模板和详细示例时，阅读 references/details.md。
13. 使用包含聚合类型的 stream ID，例如 `Order-{uuid}`。
14. 包含 correlation/causation IDs，用于追踪。
15. 从第一天开始对事件进行版本化，为 schema 演进做计划。
16. 实现幂等性，使用 event IDs 进行去重。
17. 根据查询模式适当建立索引。
18. 不要更新或删除事件，事件是不可变事实。
19. 不要存储大 payload，保持事件小。
20. 不要跳过乐观并发控制，以防止数据损坏。
21. 不要忽略 backpressure（背压），要处理慢消费者。

适用边界 · 注意事项

• 选择 Kafka 时，不适用于需要按 per-stream 查询的场景。
• 选择 DynamoDB 时，存在查询限制，不适合复杂查询模式。
• 选择 Marten 时，仅适用于 .NET 生态。