这种模式看似自然，实则暗藏隐患——它让数据库既是业务数据的存储地，又是系统间通信的枢纽，久而久之，这个原本应该专注查询与事务的组件，被迫承担了太多不属于它的职责。
于是，它变得臃肿、脆弱、难以维护，一旦出问题，恢复成本极高。
但有没有一种可能，让数据库回归它最本真的角色？让它不再背负“消息源”“审计日志”“集成中心”的重担，而是专注于一件事：快速响应查询。这正是CQRS（命令查询职责分离）加事件溯源（Event Sourcing）架构带给我们的革命性视角。它的核心不是技术堆叠，而是一次彻底的范式转移——从“先写库再发消息”，到“只发事件，其余交给系统自动处理”。这个转变听上去简单，实则撬动了整个微服务生态的底层逻辑。
有这样一个场景：你开发了一个用户注册功能。
在传统架构中，请求进来后，你的服务会先调用数据库插入一条user记录，成功后再往Kafka发一条“用户已创建”的消息。但如果数据库写成功了，消息却没发出去怎么办？或者消息发出去了，下游消费失败了又该怎么办？这类问题催生了复杂的事务消息机制、死信队列、补偿事务，甚至人工干预。
而在事件溯源的世界里，这一切都不再发生。你根本不会直接操作数据库。相反，你的服务只是向事件存储（Event Store）提交一个“UserRegistered”事件。仅此而已。
接下来会发生什么？
事件存储会把这个事件广播给所有订阅者，包括你自己的OLTP数据库服务。
是的，你的数据库服务现在只是一个普通的HTTP消费者。它监听某个端点，收到“UserRegistered”事件后，才去自己的表里插入一行数据。
这意味着，数据库不再是源头，而是一个派生结果。它和其他分析系统、缓存、搜索引擎、外部API对接服务一样，都是事件的消费者。这种地位的平等化，带来了前所未有的灵活性和鲁棒性。
最震撼的一点是：你的数据库现在可以随时丢弃、重建。假设某天你发现表结构设计不合理，想做一次大重构。传统做法是写复杂的迁移脚本，小心翼翼地加字段、改索引，生怕影响线上流量。
但在事件溯源体系中，你只需要清空数据库，然后从事件存储中重放所有历史事件，新的表结构就会自动构建出来。整个过程就像用录像带重新播放一遍系统的历史，不需要CDC工具，不需要WAL日志恢复，也不依赖任何数据库内置的复制机制——因为真正的“真理”不在数据库里，而在事件流中。
更进一步，事件本身携带的是“意图”，而不是“状态”。这是事件溯源最精髓的部分。
比如，用户误删了账户，传统系统通常会执行UPDATE或DELETE语句，CDC捕获到的是最终状态的变化。但下游系统只知道“这个人没了”，却不知道“为什么没了”。而在事件溯源中，你发出的是“UserDeleted”事件，甚至可以细分为“UserDeletedByMistake”和“UserDeletedCorrective”这样的修正事件。每一个消费者在重放时都能理解完整的业务意图，自动做出一致的反应，无需额外的人工补偿逻辑。
这种设计对数据修正尤其友好。当发现某批数据处理错误时，传统做法往往是直接修改数据库记录，然后手动通知相关方。但这种方式破坏了数据的不可变性，也让审计变得模糊。
而在事件驱动的世界里，你不修改历史，而是追加一个“纠正事件”。比如原本有个“OrderShipped”事件是错的，你就发一个“OrderShipmentReversed”加一个正确的“OrderShippedAgain”事件。所有系统在回放时都会经历这个“纠错路径”，从而保证最终状态的一致性。这就像会计中的红字冲销法，保留了完整的决策痕迹。
还有一个常被忽视的优势是事件日志的无限保留能力。在基于WAL或CDC的系统中，数据库只保留有限时间的日志，一旦超过保留周期，历史变更就永远丢失了。这意味着如果某个服务宕机一周才恢复，它可能永远无法补齐这段时间的数据。
但事件存储不同，它本身就是为长期留存设计的。哪怕一个服务离线三个月，它依然可以从上次消费的偏移量继续拉取事件，逐步追平状态。这种“无限游标”的特性，极大提升了系统的容错能力和可恢复性。
当然，很多人会问：我们团队规模不大，每天才几万条事件，有必要搞这么复杂吗？恰恰相反，正因为你不是超大规模系统，才更适合采用事件优先的架构。大型互联网公司往往因为历史包袱和技术惯性，不得不依赖高吞吐的CDC管道和定制化的WAL解析器，而中小团队反而有机会从一开始就选择更干净、更可持续的路径。你不需要一开始就搭建完美的事件平台，可以从一个简单的HTTP回调服务开始，逐步演化。
更重要的是，这种架构让你的系统天然具备了丰富的审计能力。每一条事件都是一个带有时间戳、来源、上下文的动作记录，比传统数据库的audit log详细得多。你可以轻松回答“谁在什么时候因为什么做了什么”这类问题，而这在合规、风控、产品分析等场景中价值巨大。
回到最初的问题：数据库到底应该扮演什么角色？它不该是系统的中心，而应是一个高性能的查询引擎。真正的“单一事实来源”应该是事件流。当你把数据库从集成枢纽的位置上解放出来，整个系统的耦合度骤降，扩展性上升，故障隔离能力增强。每个服务都可以按照自己的节奏消费事件，使用最适合自己的存储方案，而不必被统一的数据库 schema 所绑架。
这不是一场技术炫技，而是一种回归本质的思考。我们曾经以为数据库是系统的基石，但现在我们意识到，真正支撑业务演进的，是那些不断发生的业务动作——也就是事件。
当你的架构围绕“发生了什么”而不是“现在是什么”来构建时，你会发现，系统变得更清晰、更健壮、更有生命力。