Backend & APIChọn theo cách dữ liệu được tiêu thụ, không theo độ phổ biến.
Kafka — log phân tán, message được giữ lại theo retention và consumer đọc bằng offset. Chọn khi:
- Cần replay: thêm service mới muốn đọc lại lịch sử, hoặc phải chạy lại sau khi sửa bug.
- Nhiều nhóm consumer độc lập cùng đọc một luồng, mỗi nhóm giữ offset riêng.
- Throughput rất cao, cần thứ tự theo key, hoặc cần stream processing.
Đánh đổi: vận hành nặng hơn, không có định tuyến linh hoạt, không có retry/DLQ sẵn ở tầng broker.
RabbitMQ — message broker cổ điển, message biến mất sau khi ack. Chọn khi:
- Cần định tuyến linh hoạt (topic/headers exchange), fan-out theo quy tắc.
- Task queue: job nền, gửi mail, xử lý ảnh — mỗi việc chỉ một worker làm.
- Cần TTL, priority, per-message ack, DLX sẵn có.
Đánh đổi: không phù hợp để lưu trữ và replay lịch sử (dù stream của RabbitMQ đã thu hẹp khoảng cách này).
Redis Stream — cấu trúc dữ liệu trong Redis, có consumer group và ack. Chọn khi:
- Đã có Redis trong hệ thống, khối lượng vừa phải, muốn tránh thêm một hạ tầng phải vận hành.
- Độ trễ cực thấp, chấp nhận rủi ro mất dữ liệu ở mức persistence của Redis.
Đánh đổi: dữ liệu nằm trong bộ nhớ nên phải giới hạn độ dài stream; đảm bảo bền vững yếu hơn hai lựa chọn trên.
Cách trả lời tốt: nêu tiêu chí quyết định trước — có cần replay không, một hay nhiều nhóm consumer, khối lượng bao nhiêu, đội có vận hành nổi cụm mới không — rồi mới chọn.