再デプロイしたら、すでに送ったプッシュがまた飛んだ — FCM通知の重複送信を止める

1人開発でサーフィン予報アプリを運営しながら遭遇した、プッシュ通知の重複送信事故とその解決過程をまとめました。
特定の条件を満たしたときにユーザーへ通知を送る、よくある機能ですが、サーバーを再デプロイするたびに
「すでに送った通知」が再び送られる問題が繰り返し発生しました。

■ 問題

• 再デプロイ/再起動のたびに同じ通知が重複送信される
• ローカルでは再現しにくく、デプロイ直後にしか起きないため原因の特定が難しかった

■ 原因

• 重複防止（dedup）状態をサーバーメモリにしか持っていなかった
• 再デプロイするとプロセスが新しく立ち上がり、その状態が丸ごとリセットされる → 「未送信扱い」になって再送される

■ 解決

• dedupキーを起動時にDBから再投入する（seed-on-boot）構成に変更 → 再デプロイ後も状態を維持
• 「条件が変わった瞬間だけ通知する」方式が、その間の重みの変化を取りこぼす問題も発見
  → 理由を蓄積して段階的に引き上げる（エスカレーション）方式に切り替え
• FCMトークンは1端末1個の原則で整理（トークン更新・重複トークン処理を含む）

■ 教訓

• 通知dedupのように「一度だけ起きるべき」状態をインメモリだけに置くと、デプロイ自体がバグになる
• 状態のライフサイクルはプロセスではなく永続ストレージ基準で設計すべき
• トリガーは「遷移時点」より「現在の状態」を基準に判断したほうが取りこぼしが少ない

サーバープッシュ/通知、cron・バッチ、重複防止ロジックを扱う人に参考になる実践事例です。