实时数据账单像打车：路程没变，频繁起步也会更贵。Kafka——负责保存并分发消息的事件日志——处理大流量并不一定吃力，真正可能压垮它的是大量小请求。作者认为，成本上涨常常不只因为数据变多，还因为消息被反复复制、编码和解码，以及机器长期留着闲置容量。
最具体的排查点是“批量”。作者曾调整 Kafka 生产者的批处理配置，称 broker（处理消息的服务器）CPU 使用率下降约 50%，原有硬件因此多用了更久。道理并不复杂：把多条消息凑成一批再发送，可以减少请求次数，也通常更利于压缩。反过来，几千个生产者不断发送零碎数据，就会制造大量额外开销。
这份清单的价值，是把降本从“换更便宜的机器”拉回系统设计：批量大小是否过小，消费者是否收到一点数据就发起读取，序列化是否重复，Flink 保留的状态和检查点是否过重，文件是否碎得太多。文中的约 50% 降幅来自作者个人案例，并非所有管线都能复现；更稳妥的做法是先看批量、排队时间等指标，再逐项调参。