retention.ms là mức *sàn*, không phải hạn chót: việc dọn chạy theo chu kỳ 5 phút và chỉ xoá nguyên cả segment. retention.bytes tính theo từng partition và làm tròn lên một segment, nên đĩa thật gấp 3,4 lần con số bạn viết. Đây là công thức dự trù đĩa đúng, và vì sao 'xoá sau 30 ngày' không phải một bảo đảm tuân thủ.
Nối hai dòng dữ liệu là việc phổ biến nhất và dễ làm sai nhất trong Kafka Streams. Tôi dựng một phép nối rồi chỉ đổi độ dài cửa sổ: kết quả đi từ đầy đủ xuống bằng không, không một dòng log. Cửa sổ nối so thời gian sự kiện, nên nó phải khớp khoảng cách thật trong nghiệp vụ — và cái giá của cửa sổ dài tỉ lệ với lưu lượng, không với độ dài.
Tôi dựng cả Kafka lẫn RabbitMQ trên cùng một máy, ném 200.000 tin vào mỗi bên và đo. Kafka thắng rõ về tốc độ. Nhưng khác biệt quyết định lựa chọn lại nằm ở chỗ khác hẳn: với RabbitMQ đọc xong là tin biến mất, với Kafka đọc xong tin vẫn còn — và đó là khác biệt kiến trúc, không phải hiệu năng.
Nâng cấp Kafka không cần dừng dịch vụ, quy trình ngắn hơn nhiều người nghĩ. Tôi chạy nó thật trên cụm đang có producer và consumer hoạt động: thay từng broker, ISR đầy lại sau 1–22 giây, không mất tin. Nhưng nhị phân mới không có nghĩa giao thức đã mới — và khoảng cách đó là một cửa sổ lùi được đặt ra có chủ ý.
Chiến lược chia mặc định (RangeAssignor) chia riêng từng topic và làm tròn cùng một phía, nên phần dư dồn hết lên một consumer: hai topic lệch 4:2, năm topic lệch 10:5. Cộng với chuyện khởi động lại một consumer gây tới hai lần cân bằng toàn nhóm — và một dòng group.instance.id xoá sạch cả hai.
Cân bằng lại nhóm consumer được vẽ nhiều mà đo ít. Tôi bắt từng sự kiện kèm dấu thời gian: kiểu 'nhả hết' xong trong 4 ms không ai để ý, còn kiểu hợp tác giữ được partition đang chạy nhưng mỗi partition nhường mất 3 giây — tổng đắt gấp 375 lần. Lời khuyên 'luôn dùng cooperative' chỉ đúng khi ngắt một partition là đắt.