Triển khai lại thì push đã gửi lại tiếp tục được gửi — Khắc phục lỗi gửi trùng thông báo FCM

Bài viết tổng hợp sự cố gửi trùng thông báo push và quá trình khắc phục khi vận hành một ứng dụng dự báo lướt sóng do một người tự phát triển.
Đây là một tính năng phổ biến: gửi thông báo cho người dùng khi một điều kiện cụ thể được đáp ứng, nhưng mỗi lần triển khai lại máy chủ,
vấn đề "thông báo đã gửi rồi" lại tiếp tục được gửi lặp lại.

■ Vấn đề

• Cùng một thông báo bị gửi trùng mỗi khi triển khai lại/khởi động lại
• Khó tái hiện ở môi trường local, và chỉ bùng phát ngay sau khi triển khai nên rất khó tìm nguyên nhân

■ Nguyên nhân

• Trạng thái chống trùng lặp (dedup) chỉ được giữ trong bộ nhớ máy chủ
• Khi triển khai lại, tiến trình được khởi chạy mới và toàn bộ trạng thái đó bị reset → bị coi như "chưa gửi", nên lại gửi tiếp

■ Cách giải quyết

• Chuyển sang cấu trúc nạp lại khóa dedup từ DB khi khởi động (seed-on-boot) → giữ được trạng thái ngay cả khi triển khai lại
• Đồng thời phát hiện cách làm 'chỉ thông báo đúng lúc điều kiện thay đổi' có vấn đề là bỏ lỡ các thay đổi trọng số trong khoảng giữa
  → chuyển sang cách tích lũy lý do và nâng dần theo từng mức (escalation)
• Sắp xếp lại token FCM theo nguyên tắc 1 thiết bị 1 token (bao gồm làm mới token và xử lý token trùng)

■ Bài học rút ra

• Nếu trạng thái kiểu dedup thông báo, tức loại trạng thái "chỉ nên xảy ra đúng một lần", chỉ được đặt trong in-memory thì việc triển khai sẽ lập tức trở thành lỗi
• Cần thiết kế vòng đời của trạng thái dựa trên kho lưu trữ bền vững, không phải dựa trên tiến trình
• Với trigger, đánh giá theo 'trạng thái hiện tại' sẽ ít bị bỏ sót hơn so với chỉ nhìn vào 'thời điểm chuyển trạng thái'

Đây là một ví dụ thực tế đáng tham khảo cho những ai xử lý server push/thông báo, cron·batch, và logic chống trùng lặp.