M6 · Notification

Milestone này nhẹ hơn M5 nhưng có nhiều bẫy nhỏ. Mục tiêu: email xác nhận vé không mất, không gửi 2 lần, không bị marketing chen lên trước.

1. Bối cảnh & bài toán

Sau khi booking CONFIRMED, khách phải nhận email/SMS vé. Cùng lúc team marketing gửi 200k email khuyến mãi. Nếu làm ngây thơ:

• Auto ack: consumer nhận message rồi chết khi đang gọi SMTP → email mất.
• Requeue ngay khi lỗi: SMTP down → message quay vòng hàng nghìn lần/giây, đốt CPU (hot loop).
• Không dedupe: retry sau timeout SMTP → khách nhận 3 email vé giống nhau.
• Chung một hàng đợi FIFO: email vé đứng sau 200k email marketing, tới trễ 30 phút.
• Classic queue một node: node RabbitMQ chết → mất message.

2. Ôn lại trước khi code

• Notification: tách kênh, template, ưu tiên, rate limit nhà cung cấp, dedupe.
• Exchange & routing: topic exchange, routing key theo loại thông báo.
• ACK & publisher confirm: manual ack, nack/reject, prefetch, confirm phía producer.
• Quorum queue: Raft, x-delivery-limit, quorum queue không hỗ trợ priority kiểu classic như thế nào.
• Retry, TTL, DLX: retry có delay bằng TTL + DLX, DLQ sau N lần.
• RabbitMQ hay Kafka: vì sao saga dùng Kafka còn notification dùng RabbitMQ.
• M5 · Saga + Outbox: event BookingConfirmed đến từ outbox; inbox dùng lại ý tưởng dedupe.

3. Đề bài

Luồng

booking.events (Kafka) ── BookingConfirmed ──▶ notification-service (bridge consumer)
                                                   │ publish (publisher confirm)
                                                   ▼
                               exchange notify.x (topic)
                     ┌─────────────────┴──────────────────┐
           rk notify.ticket.*                     rk notify.marketing.*
                     ▼                                    ▼
          q.notify.ticket (quorum)               q.notify.marketing (quorum)
          consumers: 8, prefetch 10              consumers: 2, prefetch 50
                     │ lỗi tạm thời                        │
                     ▼                                    ▼
          q.notify.retry.{10s,1m,5m} (TTL → DLX quay về queue gốc)
                     │ quá N lần
                     ▼
          q.notify.dlq (quorum) + alert

Ưu tiên: quorum queue không có priority đầy đủ như classic, nên đề yêu cầu ưu tiên bằng tách queue + chia consumer/prefetch. Nếu bạn muốn dùng x-max-priority trên classic queue hoặc priority của quorum queue (RabbitMQ 4.x), ghi ADR so sánh.

API

Schema

CREATE TABLE notifications (
  id              UUID PRIMARY KEY,
  dedupe_key      TEXT NOT NULL UNIQUE,    -- vd 'ticket:' || booking_id
  type            TEXT NOT NULL,           -- TICKET_CONFIRMATION | MARKETING
  channel         TEXT NOT NULL,           -- EMAIL | SMS
  recipient       TEXT NOT NULL,
  payload         JSONB NOT NULL,
  status          TEXT NOT NULL,           -- PENDING | SENDING | SENT | FAILED | DEAD
  attempts        INT  NOT NULL DEFAULT 0,
  provider_msg_id TEXT,
  last_error      TEXT,
  created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
  sent_at         TIMESTAMPTZ
);

Message

{
  "notificationId": "uuid",
  "dedupeKey": "ticket:booking-uuid",
  "type": "TICKET_CONFIRMATION",
  "channel": "EMAIL",
  "to": "user@example.com",
  "template": "ticket-confirmed",
  "data": { "bookingId": "…", "event": "…", "seats": ["A1","A2"] }
}
headers: x-attempt: 2

Cấu hình cần có

spring.rabbitmq:
  host: ${RABBIT_HOST}
  username: ${RABBIT_USER}
  password: ${RABBIT_PASSWORD}
  publisher-confirm-type: correlated
  publisher-returns: true
  listener.simple:
    acknowledge-mode: manual
    default-requeue-rejected: false
notification:
  retry.delays: [10s, 1m, 5m]
  retry.max-attempts: ?
  ticket.concurrency: ?
  marketing.concurrency: ?

Skeleton

@Configuration
class NotificationTopology {
    // TODO: Declarables: notify.x, q.notify.ticket (x-queue-type=quorum, x-dead-letter-exchange=…),
    //       q.notify.marketing, retry queues với x-message-ttl, q.notify.dlq
}

public interface EmailSender {
    /** Trả providerMsgId. Ném TransientSendException (retry được) hoặc PermanentSendException (vào DLQ ngay). */
    String send(String to, String template, Map<String, Object> data, String idempotencyKey);
}

@Component
class TicketNotificationListener {
    // @RabbitListener(queues = "q.notify.ticket", concurrency = "${notification.ticket.concurrency}")
    void on(NotificationMessage m, Channel ch, @Header(AmqpHeaders.DELIVERY_TAG) long tag) {
        // TODO: claim dedupe (PENDING → SENDING), gửi, SENT, basicAck
        // TODO: lỗi tạm thời → publish sang retry queue theo x-attempt rồi ack
        // TODO: quá N lần / lỗi vĩnh viễn → DLQ
    }
}

4. Acceptance criteria

1. Mỗi BookingConfirmed sinh đúng 1 dòng notifications và tối đa 1 email gửi thành công, kể cả khi event Kafka tới 5 lần.
2. Queue chính và DLQ là quorum queue (rabbitmqctl list_queues name type cho thấy quorum).
3. Consumer dùng manual ack; kill notification-service khi đang gửi → message được giao lại, không mất.
4. Mock SMTP lỗi 100%: message thử đúng N lần với độ trễ tăng dần (10s, 1m, 5m), sau đó vào q.notify.dlq, status = DEAD, có alert.
5. Lỗi vĩnh viễn (email sai định dạng) vào DLQ ngay, không retry.
6. Khi 50k marketing đang xếp hàng, email vé từ lúc CONFIRMED tới lúc gửi p95 < 5s.
7. Replay từ DLQ gửi lại được và vẫn không trùng với lần đã gửi thành công.
8. Không hot loop: khi SMTP down, CPU notification-service < 30% và số lần giao lại tuân theo delay.

5. Test cases

@Testcontainers
@SpringBootTest
class NotificationRetryDlqIT {
    @Container static RabbitMQContainer rabbit = new RabbitMQContainer("rabbitmq:4.0-management");
    @Container static PostgreSQLContainer<?> pg = new PostgreSQLContainer<>("postgres:16");

    @MockitoBean EmailSender sender;

    @Test
    void permanentFailure_goesToDlqAfterNAttempts() {
        // TODO: sender luôn ném TransientSendException
        // TODO: rút ngắn delay qua property (vd 200ms) cho test
        // TODO: await: DLQ có 1 message, verify(sender, times(N)), status DEAD
    }

    @Test
    void duplicateEvent_sendsOnce() { /* TODO */ }
}

6. Failure scenarios

7. Benchmark / số liệu cần thu

• Độ trễ email vé (CONFIRMED → SENT) p50/p95 khi không tải và khi có 50k marketing đang chờ.
• Throughput mỗi queue (msg/s) với prefetch 1/10/50.
• Thời gian từ lỗi đầu tiên tới lúc vào DLQ, so với tổng delay cấu hình.
• Lưu tại docs/benchmarks/m06-notification.md.

8. Checklist hoàn thành

• ☐ Acceptance criteria có test tự động và xanh.
• ☐ Mọi failure scenario đã chạy thật, ghi kết quả.
• ☐ Benchmark trong docs/benchmarks/.
• ☐ ADR: cách làm priority trên quorum queue; vì sao bridge Kafka → RabbitMQ.
• ☐ Không hardcode password RabbitMQ/SMTP, dùng ${ENV}.
• ☐ Topology khai báo bằng code (Declarables), không tạo tay trên UI.
• ☐ Có runbook replay DLQ trong docs/.
• ☐ Đã qua review và phỏng vấn của AI.

Đúng triệu chứng hot loop. Gợi ý:

• Requeue đặt message về đầu queue, không có khái niệm "chờ". Delay phải đến từ chỗ khác.
• Hướng 1: queue retry không có consumer, đặt x-message-ttl + x-dead-letter-exchange trỏ về exchange gốc. Hết TTL, message tự quay lại. Một queue cho mỗi mức delay.
• Hướng 2: plugin rabbitmq_delayed_message_exchange. Tự tìm hiểu giới hạn của nó (lưu ở đâu, có replicate không) trước khi chọn.
• Đếm số lần: header x-death do broker thêm, hoặc header x-attempt tự quản. Quorum queue còn có x-delivery-limit — tự kiểm nó đếm cái gì và khác x-death ra sao.

Câu trả lời thật: không tuyệt đối nếu provider không hỗ trợ idempotency. Gợi ý hướng nghĩ:

• Gửi email là hiệu ứng ngoài DB, giống gọi PSP ở M3. Bạn không thể đặt nó vào cùng transaction.
• Thu hẹp cửa sổ: chuyển PENDING → SENDING có điều kiện trước khi gửi; lần giao lại thấy SENDING quá lâu thì quyết định gì? Gửi lại (chấp nhận trùng hiếm) hay hỏi provider theo idempotencyKey?
• Nhiều provider nhận header idempotency/message-id; mock SMTP của bạn nên hỗ trợ để test T6.7.
• Viết rõ trong ADR: email vé chấp nhận "at-least-once, trùng hiếm" hơn là "có thể mất".

Bạn vừa phát hiện ưu tiên ở queue chưa đủ, tài nguyên phía sau cũng phải chia. Gợi ý:

• Nghĩ lại bulkhead ở M4: mỗi loại thông báo một pool kết nối/semaphore tới SMTP riêng.
• Rate limit marketing (token bucket) để luôn chừa dung lượng cho email vé.
• Đo T6.6 trước và sau khi chia pool, ghi số vào benchmark.

Checklist review code AI sẽ soi

• acknowledge-mode: manual, ack sau khi cập nhật DB; mọi nhánh đều ack hoặc nack (không để message unacked mãi).
• Không requeue=true cho lỗi; default-requeue-rejected: false.
• Phân loại lỗi tạm thời / vĩnh viễn rõ ràng.
• Bridge Kafka → RabbitMQ chờ publisher confirm rồi mới commit offset Kafka.
• Queue quorum, khai báo bằng code, có DLX; DLQ có consumer cảnh báo hoặc alert theo độ dài.
• Unique dedupe_key; trạng thái SENDING có điều kiện; idempotency key truyền cho provider.
• Prefetch hợp lý, consumer marketing không chiếm hết pool SMTP.
• Không log nội dung email/PII đầy đủ.

Câu hỏi phỏng vấn

1. Vì sao saga dùng Kafka mà notification dùng RabbitMQ?

🇻🇳 Saga cần log có thứ tự theo booking và replay được, Kafka hợp. Notification là hàng đợi công việc: cần ack từng message, retry có delay, DLQ, chia ưu tiên — RabbitMQ làm sẵn những thứ đó.

🇬🇧 The saga needs an ordered, replayable log per booking, which suits Kafka. Notifications are a work queue needing per-message ack, delayed retry, DLQ and priority, which RabbitMQ gives out of the box.

2. Bạn làm retry có delay và DLQ thế nào?

🇻🇳 Lỗi tạm thời thì đẩy sang queue retry có TTL, hết TTL dead-letter về queue gốc. Đếm số lần bằng header; quá N lần hoặc lỗi vĩnh viễn thì vào DLQ và bắn alert, có API replay.

🇬🇧 On a transient error I move the message to a retry queue with a TTL that dead-letters back to the main queue. I count attempts in a header; after N attempts or a permanent error it goes to the DLQ with an alert and a replay API.

3. Làm sao khách không nhận 2 email vé?

🇻🇳 Dedupe key duy nhất theo booking trong DB, chuyển trạng thái có điều kiện trước khi gửi, và truyền idempotency key cho provider. Vẫn còn cửa sổ nhỏ nếu provider không hỗ trợ, tôi chấp nhận trùng hiếm hơn là mất email.

🇬🇧 A unique dedupe key per booking, a conditional state change before sending, and an idempotency key passed to the provider. There's still a tiny window if the provider doesn't support it; I prefer a rare duplicate over a lost ticket email.

4. Quorum queue khác classic queue thế nào?

🇻🇳 Quorum queue replicate qua Raft trên nhiều node, an toàn khi một node chết, có delivery-limit sẵn. Đổi lại tốn tài nguyên hơn và một số tính năng như priority hạn chế hơn classic.

🇬🇧 Quorum queues replicate via Raft across nodes, survive a node failure and have a built-in delivery limit. The trade-off is more resource use and more limited features like priority compared to classic queues.

Cách nhớ ngắn gọn

Ack thủ công, chờ có hẹn, quá N thì DLQ, vé đi làn riêng, gửi có khoá dedupe.