Bạn thiết kế notification service dùng chung cho cả công ty ra sao?

Question

IT Interview Practice · Accepted Answer

Xây một service mà mọi team gọi với một **loại thông báo + người nhận**, để service tự quyết định channel, template, tuỳ chọn người dùng và độ ưu tiên. Nước đi thiết kế then chốt là **priority lane** — một OTP không thể chờ sau một đợt marketing 2 triệu user.

## Kiến trúc

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

## Thành phần và luồng

- **Notify API** nhận request có kiểu: `{type: "otp", user, data}`. Người gọi không bao giờ chọn channel hay viết nội dung — service sở hữu phần đó, nên đổi template chỉ ship một lần.
- **Type → policy**: mỗi **type** ánh xạ tới một policy. *OTP* ưu tiên cao, SMS+Push, bỏ qua opt-out marketing, hết hạn sau 60s. *Transactional* (biên nhận, reset mật khẩu) ưu tiên cao, tôn trọng tuỳ chọn channel. *Marketing* ưu tiên thấp, đi bulk lane, tuân thủ nghiêm opt-out và quiet hours.
- **Priority lane** là các Kafka topic riêng với consumer group riêng. High lane luôn gần rỗng và rút cạn trong vài mili-giây; bulk lane có thể ứ vài phút mà không chạm tới độ trễ của OTP. Đây là quyết định quan trọng nhất.
- **Preference service** được kiểm tra theo từng người nhận: đã opt-out chưa? có đang quiet hours? bật/tắt theo channel? có frequency cap? Marketing vi phạm một tuỳ chọn bị loại ngay tại đây.
- **Template engine** render nội dung đã bản địa hoá từ một template có version + biến, nên nội dung và code tách rời nhau.
- **Channel adapter** bọc FCM/APNs, SendGrid, Twilio sau một interface chung, mỗi cái có rate limiter, retry và DLQ riêng (cùng kỷ luật fan-out như mọi bộ gửi hàng loạt).

## Góc nhìn phỏng vấn

Người phỏng vấn dò xem bạn có tách **mối quan tâm (concerns)** không: nhiều ứng viên xây một monolith gửi email trực tiếp, rồi phát hiện đợt marketing làm nghẽn OTP. Gọi đúng tên *priority lane*, *thực thi preference*, và *idempotency key* (để request retry không thông báo trùng) là tín hiệu senior. Khá thì thêm channel; xuất sắc thì giải thích vì sao OTP và marketing không bao giờ được chung queue và một **fallback chain** (Push hỏng → SMS) hoạt động ra sao.

## Đánh đổi và kịch bản hỏng

- **Một service vs mỗi team tự làm**: tập trung cho ta preference, throttle và audit nhất quán, nhưng trở thành phụ thuộc quan trọng — nó phải HA, nếu không sự cố OTP đăng nhập chặn cả công ty.
- **Real-time vs chi phí**: SMS đắt và chậm; ưu tiên Push/In-App và chỉ fallback SMS cho các type giá trị cao.
- **Kịch bản hỏng**: provider sập thì kích hoạt fallback chain, không fail cứng. **Dedup key** ngăn một lần gửi lại của queue phát OTP hai lần. Theo dõi SLO gửi theo từng type — email marketing trễ thì không sao, OTP trễ là một sự cố.

Kiến trúc

Thành phần và luồng

Góc nhìn phỏng vấn

Đánh đổi và kịch bản hỏng

Câu hỏi liên quan