Khả năng đọc lại dữ liệu cũ là thứ phân biệt Kafka với hàng đợi truyền thống. Tôi đo bốn cách tua offset, và tìm ra cái bẫy trong cách dùng nhiều nhất: --to-datetime với mốc quá dữ liệu không từ chối mà âm thầm lùi về 'latest' — nhảy tới cuối, ngược hẳn ý định — kèm một thông báo 'empty' hoàn toàn gây hiểu nhầm.
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ố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.
Khi một tin không xử lý được, phản xạ tự nhiên là thử lại. Tôi đo cái giá đó ở bốn mức tỉ lệ hỏng: ở mức 50%, thử lại tại chỗ cho 30 tin/giây còn đẩy sang DLQ cho 766 — chênh 25,5 lần. Chi phí của một tin hỏng không phải là chờ nó, mà là toàn bộ hàng phía sau cũng phải chờ theo.
Kafka Connect đưa dữ liệu vào ra Kafka bằng JSON cấu hình thay vì mã. Tôi dựng đường ống PostgreSQL → Kafka và đo: thông lượng hơn trăm nghìn dòng/giây, nhưng mode=incrementing mù hoàn toàn với UPDATE và DELETE — không lỗi, không log, connector vẫn xanh, trong khi hạ nguồn tính toán trên dữ liệu cũ. Cách bạn phát hiện thay đổi quyết định loại thay đổi bạn thấy được.
Xác thực trả lời 'bạn là ai', ACL trả lời 'bạn được làm gì'. Tôi bật ACL trên cụm thật rồi cấp quyền từng lớp: broker bị chính luật của nó chặn vì lưu lượng nội bộ là ANONYMOUS, đọc cần tới hai ACL, và lỗi của producer idempotent nói về cụm chứ không nói về topic. Mỗi lỗi đều chỉ sai chỗ cần sửa.