Hệ thống thông báo

Tầng 1 đọc người nhận theo lô 1.000, lọc preference, tạo Delivery. Tầng 2 có queue riêng cho push, email, SMS, in-app, mỗi kênh tách luồng giao dịch và luồng marketing. Channel worker của mỗi kênh scale độc lập và đặt số request song song theo hạn mức provider. Khi dùng Kafka thì key theo userId để thông báo của một người đi đúng thứ tự (sharded channel, Microservices Patterns §3.3.5).

Đánh đổi: Nhiều queue và worker hơn phải theo dõi; cần đo lag từng queue để biết kênh nào đang chậm.

Nguồn: Grokking Modern System Design · ch.17 Distributed Messaging Queue ↗ · bài "System Design: The Distributed Messaging Queue", mục "Motivation" (Priority queue: mỗi mức ưu tiên một queue) ; Microservices Patterns ↗ (.zip) · ch.3 · §3.3.5 Competing receivers and message ordering (tr. 94–95) ; Grokking Modern System Design · ch.23 Distributed Task Scheduler ↗ · bài "Design Considerations", mục "Prioritization"

Preference lưu hash Redis theo user, xóa key khi người dùng cập nhật. Mỗi lần gửi marketing tăng bộ đếm cửa sổ trượt user:{id}:mkt:{ngày}, quá 3 thì bỏ hoặc gộp thành một tin tóm tắt (sliding window counter, Grokking ch.19). OTP có giới hạn riêng, ví dụ 5 tin/10 phút, để chặn kẻ xấu spam SMS tốn tiền. Giờ yên lặng thì dời send_at thay vì bỏ.

Đánh đổi: Cache có thể lệch vài giây sau khi người dùng vừa tắt kênh; bộ đếm trong Redis mất khi failover thì có thể gửi vượt giới hạn một chút.

Nguồn: Redis in Action ↗ · ch.3 · §3.4 Hashes (tr. 48–50) ; Grokking Modern System Design · ch.16 Distributed Cache ↗ · bài "Background of Distributed Cache", mục "Cache invalidation" ; Grokking Modern System Design · ch.19 Rate Limiter ↗ · bài "Rate Limiter Algorithms", mục "Sliding window counter algorithm" và bài "Design of a Rate Limiter", mục "High-level design" (luật marketing 5 tin/ngày của Lyft)

Lỗi 4xx vĩnh viễn (token hết hạn, email bounce) không retry, cập nhật DeviceToken hoặc đánh dấu địa chỉ hỏng. Lỗi 5xx/timeout thì backoff. Circuit breaker cho từng provider (Microservices Patterns §3.2.3): tỉ lệ lỗi vượt ngưỡng thì ngắt và chuyển SMS/email sang nhà cung cấp thứ hai. Tin có hạn dùng (OTP 5 phút) mang expires_at, quá hạn thì bỏ thay vì gửi muộn.

Đánh đổi: Duy trì hai provider tốn công đăng ký brandname/mẫu tin; timeout có thể là provider đã gửi thật nên chuyển sang provider khác có thể gây trùng.

Nguồn: Microservices Patterns ↗ (.zip) · ch.3 · §3.2.3 Handling partial failure using the Circuit breaker pattern (tr. 77–80) ; Building Microservices ↗ (.zip) · ch.11 Microservices at Scale · mục "Timeouts", "Circuit Breakers" (tr. 211–214)

delivery_id = hash(notificationId, userId, channel) nên fan-out chạy lại cũng sinh đúng id cũ. Channel worker SET dedup:{delivery_id} NX với TTL 24 h trước khi gọi provider, và chuyển Delivery sang SENDING; thấy key đã có thì bỏ qua. Đây là idempotent consumer (Microservices Patterns §3.3.6). Với push, gửi kèm collapse key (FCM) hoặc apns-collapse-id để thiết bị chỉ hiện một bản.

Đánh đổi: Worker chết sau SET NX mà chưa gửi thì tin bị kẹt; cần job quét Delivery SENDING quá 1 phút để gửi lại, chấp nhận khả năng trùng rất nhỏ.

Nguồn: Microservices Patterns ↗ (.zip) · ch.3 · §3.3.6 Handling duplicate messages, mục "Tracking messages and discarding duplicates" (tr. 95–97) ; Redis in Action ↗ · ch.6 · §6.2.3 Building a lock in Redis (SETNX, tr. 120–123)

Lưu múi giờ dạng tên IANA, không lưu offset, để tự đúng khi có giờ mùa hè. Fan-out nhóm người nhận theo múi giờ, mỗi nhóm thành job ở bucket phút tương ứng; scheduler gom job đến hạn theo lô rồi đẩy vào hàng đợi theo độ ưu tiên (Grokking ch.23); nhiều instance chia bucket bằng khóa có thời hạn trong Redis (Redis in Action §6.2.5). Marketing có delay tolerance dài hơn giao dịch (Grokking ch.23) nên được rải ngẫu nhiên trong 30 phút sau mốc để tránh đỉnh. Hủy chiến dịch bằng cách đổi trạng thái Notification; worker kiểm tra trước khi gửi.

Đánh đổi: Thêm logic múi giờ và một chiến dịch thành nhiều job; người đổi múi giờ sau khi job đã tạo vẫn nhận theo giờ cũ.

Nguồn: Grokking Modern System Design · ch.23 Distributed Task Scheduler ↗ · bài "Design of a Distributed Task Scheduler", mục "Components" (Batching and prioritization) và bài "Design Considerations", mục "Prioritization" (delay tolerance) ; Redis in Action ↗ · ch.6 · §6.2.5 Locks with timeouts (tr. 126–127)