Lời khuyên phổ biến là 'đừng dùng JSON trên Kafka, dùng Avro'. Tôi đo cả ba định dạng trên cùng dữ liệu: thô thì Avro nhỏ hơn JSON 2,5 lần nhưng mã hoá lại chậm hơn. Rồi bật nén — mà cụm nào cũng bật — và lợi thế co xuống 1,4 lần, vì nén xoá đúng phần dư thừa (tên trường lặp lại) mà Avro xoá bằng tay. Lý do thật để chọn Avro nằm ở chỗ khác.
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.
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.