アウトバウンドWebフックの再試行のための自動クリーンアップジョブは、データが増加するにつれて予期せずリソースを大量に消費する可能性があります。単純な毎晩の削除ジョブでは、増加したボリュームに対応できない場合があります。これを管理するために、クリーンアップタスクの開始をトリガーするパブリックHTTPエンドポイントをcronジョブで起動する必要があります。大規模な削除の場合、このエンドポイントは、バッチ処理されたデータセットを処理する冪等なキューワーカーに作業を委任する必要があります。リトライレジャーは、一意のバッチキーを使用して条件付き削除を行うことで、繰り返し実行されるクリーンアップアクションが意図しない破壊的な操作を引き起こさないようにするために重要です。ワーカーは、重複メッセージを安全に処理できるように設計する必要があり、それらをノーオペレーションとして扱います。リトライは一般的であり、システムはそれらを堅牢に処理する必要があるため、この冪等性は不可欠です。Node.jsのcron HTTPエンドポイントは、冪等性キーを持つ単一のバッチを迅速に公開することで、重複作業から保護できます。実際の削除は、時間制限のあるcronジョブ自体ではなく、専用のワーカーによって処理されます。キューワーカーは意図的にシンプルに設計され、1つのバッチを処理し、レコードを削除し、トランザクションが成功した後にのみ完了を承認する必要があります。この設計により、リトライは無害になります。永続的な障害に対してデッドレターキューを実装することが推奨されており、問題のあるメッセージを検査および再処理する方法を提供します。冪等性メカニズムがさまざまな障害条件下で正しく機能することを確認するために、再起動シナリオのテストが重要です。バッチID、カウント、ステータスの詳細なログ記録により、オブザーバビリティが鍵となります。キューメッセージに大量のデータを配置しないでください。複雑で複数ステップのクリーンアッププロセスには、TemporalやAirflowなどのワークフローエンジンがより適しています。説明されているパターンは、より単純な単一パスの保持タスクに最適であり、公開されているエンドポイントが必要です。運用ループには、トリガー、エンキュー、クレーム、削除、記録、および承認が含まれます。未処理のバッチの経過時間やデッドレターキューの深さなどの主要なメトリックを定期的に監視することが不可欠です。保持ポリシーを変更する前に、ドライランクエリを実行することで、誤ったデータ損失に対する安全策が提供されます。このプロセス全体は、オフアワーでも理解および管理できるほどシンプルである必要があります。