Outbox模式实践：事件分发器是否应与事件生成服务共享数据库？

结合你的低流量场景（每日最多10k请求），优先选择共享数据库的方案，原因如下：

1. 适配低流量的成本优势 #

每日10k请求属于极低流量规模，共享数据库方案的实现复杂度低、运维成本少的优势会被最大化。你不需要额外开发Generator与Dispatcher之间的API通信层，也不用处理网络调用带来的重试、超时、幂等性等额外问题，能快速落地Outbox模式的核心需求。

2. 消解共享数据库的反模式顾虑 #

微服务共享数据库确实是普遍认知中的反模式，但在低流量、业务边界高度清晰的场景下，这个反模式的副作用几乎可以忽略。你的场景里：

• Generator负责事件的写入（含事务内数据变更+事件保存）和事件的CRUD API；
• Dispatcher仅负责拉取未发送事件、调用外部服务发送、标记事件为已发送。
  两者的数据库操作完全没有重叠的业务逻辑，不会出现服务间耦合到难以维护的情况。

3. 明确CRUD API的归属 #

事件的CRUD API必须由Generator提供，因为它是事件的生成者和数据的唯一所有者。Dispatcher只负责事件的分发执行，不应该涉及事件的创建、修改操作，这样职责划分反而更清晰。

4. 潜在问题的应对方案 #

除了确保数据库连接数足够，只需额外处理两个关键细节：

• 行级锁避免重复处理：Dispatcher拉取事件时，使用SELECT ... FOR UPDATE SKIP LOCKED（或对应数据库的语法）对目标事件加行级锁，防止多个Dispatcher实例重复处理同一事件；
• 幂等性保证：发送事件到外部Kafka服务时，用事件ID作为唯一标识，确保即使因为重试导致重复调用，外部服务也不会重复生成消息。

如果未来业务流量大幅增长（比如日请求量突破100k），或者Generator和Dispatcher需要独立扩容、部署到不同环境，再考虑切换到API通信的方案——那时网络层带来的成本是为了架构扩展性必须付出的代价。

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