Event-driven, message queue và Kafka

Bài toán

Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả request. Đặt một message broker hay log (RabbitMQ, SQS, Kinesis, Kafka) ở giữa thì producer chỉ phát, consumer tự đọc theo tốc độ của mình. Đổi lại, hệ phải trả lời những câu mà gọi đồng bộ không có:

• Message mang gì: sự kiện mỏng (ID) hay toàn bộ trạng thái?
• Thứ tự: cần ở đâu, và giữ được tới mức nào khi có nhiều partition, nhiều cluster?
• Lỗi: message không xử lý được thì chặn cả hàng hay đẩy sang dead letter? Trùng và sai thứ tự thì ai chịu?
• Vận hành: broker trở thành hạ tầng dùng chung, nên nó hỏng thì hỏng nhiều thứ.

Trang này nói về luồng event giữa các service (backend). Đẩy dữ liệu tới client và fan-out một → nhiều nằm ở Realtime và fan-out; điều tiết tải ở consumer nằm ở Load shedding, rate limit và backpressure.