核心问题

如何用 ADR 记录一次 Kafka 技术选择？

真实场景

课程平台要处理大量学习行为：点击、播放、暂停、完成、搜索、收藏。产品想做实时推荐和学习分析。

团队讨论消息系统。选项包括 Redis List、RabbitMQ、Kafka。

常见误区

坏文档只写：

行为日志使用 Kafka。

这对未来没有帮助。

工程视角

更好的 ADR 会这样写：

背景：
学习行为量增长，需要异步处理并支持后续分析。

约束：
需要多消费者，推荐、报表、风控可能同时消费。
需要一定重放能力，便于修复下游计算错误。

选项：
Redis List：简单，但重放和多消费者能力不足。
RabbitMQ：适合任务分发，但长期日志流分析不是强项。
Kafka：运维复杂，但吞吐、多消费者、重放能力匹配。

决策：
选择 Kafka。

代价：
接受运维复杂度，必须补监控、告警和容量规划。

PM 可以怎么做

PM 要特别补充业务侧信息：

  • 哪些业务会消费行为数据？
  • 数据延迟可以接受多久？
  • 丢失一部分数据的后果是什么？
  • 未来是否需要回放历史事件？

Atlas Action

对任何“上 Kafka”的提议，先问：

我们需要的是异步、缓冲、重放、多消费者，还是只是想解耦？

如果只是简单异步，Kafka 可能过重。

小结

Kafka 不是先进的代名词，它是一组能力和代价。

ADR 的价值，就是把“为什么值得承担这些代价”写清楚。