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.
Chi phí của giao dịch Kafka phụ thuộc hoàn toàn vào một con số bạn tự chọn: cỡ giao dịch. Một tin một giao dịch cho 96 tin/giây, cỡ 10.000 cho 639.285 — nhanh hơn cả không giao dịch. Đó là một chi phí cố định 10,4 mili giây được khấu hao trên số tin; nhưng gói càng lớn thì tin đầu tiên chờ càng lâu, vì read_committed không thấy gì tới khi cả lô cam kết.
Kafka Streams chạy xử lý dòng ngay trong ứng dụng của bạn. Tôi đo một phép đếm đơn giản và cả ba con số đều bất ngờ: 200.000 tin vào chỉ cho 5.340 bản ghi ra, trạng thái nằm ở hai nơi, và khởi động lại ngay lập tức chậm hơn khởi động lại sau khi chờ tới 90 lần — vì bản mới đang đợi chính bóng ma của mình hết hạn.
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.
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.
Debezium đọc WAL thay vì hỏi bảng, nên nó bắt được cả UPDATE lẫn DELETE mà JDBC source bỏ sót — kèm cả giá trị 'before' và 'after'. Nhưng cái giá nằm ở phía cơ sở dữ liệu: khe sao chép ghim WAL lại cho tới khi connector xác nhận, nên một consumer chết qua đêm có thể làm đầy đĩa và chặn luôn việc ghi của hệ giao dịch.