Preview Bản nháp chờ review — title, nội dung, link có thể sửa trước khi bỏ nhãn.

“Đưa vào Kafka” chưa nói hệ làm gì. Cùng broker, hai hình học khác hẳn: 

Work queue (compete)
  1 message → đúng 1 worker xử lý việc
  (mail job, resize, “hãy charge order X”)

Fan-out (pub/sub, multi consumer group)
  1 event → nhiều app độc lập cùng “nghe”
  (billing + analytics + search index)

Nhầm topology → recovery sai: resend “cho group mình” thành double cho hàng xóm.

Work queue

  • Competing consumers, lease, DLQ cổ điển.
  • Mục tiêu thường write side: hoàn thành action, unblock khi poison.
  • Requeue/resend trong cùng “việc” thường an toàn hơn shared log.

Fan-out

  • Mỗi subscriber progress riêng (offset group / subscription).
  • A fail ≠ B fail. Resend vào bus chung = multi-tenant failure.
  • Read/projection hay nằm fan-out: order per-key, cẩn missing/wrong.

Bảng recovery (nhanh)

                 Work queue           Fan-out / shared
Requeue/retry    OK thường           OK trong group; cẩn resend bus
Resend bus       ít dùng             NO mặc định (double hàng xóm)
DLQ private      OK                  OK từng group
Ignore           theo product        read đủ: NO

Chi tiết: playbook, resend shared.

Lai trong thực tế

Event “OrderPaid” fan-out → service mail đẩy job vào work queue nội bộ. Hai tầng: bus shared + queue private. Recover mail ở queue private, không republish OrderPaid mù.

Một câu

Một việc vs một tin broadcast — đừng dùng chung một recovery.
Hỏi “mấy app nghe?” trước khi resend.