Webhook:業務処理を重複させずイベントを受け取る

要点

WebhookはHTTPでイベントを通知します。即時配信、順序、業務上の効果が厳密に1回だけであることを一律には保証しません。

サーバーとネットワーク設備の無人セキュア通路
この記事の内容

受信と処理完了を区別する

保証は提供元によって異なります。Stripeは重複の可能性と順序を保証しないことを明記しています。HTTP成功応答は、単にメモリーへ届いたことではなく、永続的な受信または予定した処理に対応させます。

状況期待する動作役立つ証拠
同じイベントが2回届く業務上の効果の重複を防ぐ。処理済みIDと永続結果。
古いイベントが遅れて届く新しい状態を無条件に上書きしない。正本の状態と遷移規則。
重い処理永続受信後に遅延実行。キュー状態とワーカー結果。
配信が欠ける提供元の規則に沿って照合・回復。特定した差分と検証済み修正。

検証可能な受信を作る

  • 提供元のプロトコルに従ってHTTPS、署名、リプレイ対策を確認します。Stripeは生の本文で署名を検証し、先にJSONを変換すると検証できなくなる場合があります。
  • 適切な受領応答の前にイベントまたは処理を永続化します。配信ID、イベントID、業務処理の冪等キーを区別します。
  • 重複、順序違い、ワーカー中断、再起動を試験します。古いイベントだけで安全に判断できなければ、正本のオブジェクト状態を取得します。

回復と照合を用意する

試行、期限、未処理イベント、提供元との照合手順を文書化します。速い受領応答が後続の失敗を隠す場合があります。最終的な業務処理も監視し、秘密や個人情報のログを制限します。

一次資料

繰り返し発生するWebhookを安全に処理します。

タイムアウトまたは応答の消失後、通知が繰り返される場合があります。信頼性は、オリジン検証、イベント識別子、および新規メッセージと重複メッセージを区別する処理に依存します。

  • プロバイダのメカニズムを使用して、各リクエストを検証します。
  • 再試行、重複、および到着順序の変更をテストします。
  • 処理後または永続キューイング後に、一貫して確認応答を行います。

一次資料:IETF RFC 9457 — Problem Details for HTTP APIs. 関連する方法:実践ガイドを読む.