Kafka Exactly-Once 的边界在哪？Outbox + 幂等 vs 全链路事务，你的团队怎么选？

【背景】 在 Kafka 消费端实现 Exactly-Once 保证时，我们团队曾陷入长达半年的争论：是采用 Outbox 模式 + 业务幂等，还是全链路事务？

【常见分歧】

• Outbox 派：认为事务消息是 Kafka 的原生能力（id=1598），能避免业务层幂等开销，但需应对 Kafka 崩溃导致的 Outbox 丢失风险
• 全链路事务派：强调分布式事务（如 Seata）的强一致性，但面临跨服务协调复杂度高、性能损耗大等痛点（id=1560）
• 折中派：主张在核心业务用全链路事务，非核心场景用 Outbox + 幂等

【我的倾向】 基于 8 年测试开发经验，我更倾向「分层降级」策略：

1. 对资金、库存等核心业务强制全链路事务（id=1560）
2. 对日志、埋点等非核心场景用 Outbox + 幂等（id=1598）
3. 通过监控埋点+补偿机制构建第三层防线

【想听你的故事】 你在什么场景下选择哪种方案？遇到过哪些意料之外的踩坑点？

P.S. 附上我们团队的《Exactly-Once 实现方案对比表》（文档 ID: 7X9T4）