Webhook リトライとは、短縮 URL のクリックイベントなどを外部システムに通知する Webhook の配信が失敗した際に、一定の間隔を空けて再送信する仕組みです。ネットワーク障害や受信側の一時的なダウンタイムで失敗した配信を、あとから届けるために使います。
リトライの待機時間を決める方法の 1 つが指数バックオフ (Exponential Backoff) です。初回失敗後 1 秒、2 回目 2 秒、3 回目 4 秒、4 回目 8 秒... と待機時間を指数的に増加させます。これにより、過負荷の受信側に再送が重なりにくくなります。ジッター (ランダムな揺らぎ) を加えると、複数の Webhook の再送が同じ時刻に集中しにくくなります。
短縮 URL サービスにおける Webhook の典型的なユースケースは、(1) クリックイベントの CRM への連携 (リードスコアリング)、(2) Slack/Teams への通知 (キャンペーンのリアルタイム監視)、(3) データウェアハウスへのイベント蓄積 (分析基盤)、(4) セキュリティアラート (不審なクリックパターンの検知) です。
設計上の重要な考慮事項として、冪等性 (Idempotency) の確保があります。リトライにより同一イベントが複数回配信される可能性があるため、受信側はイベント ID による重複排除を実装する必要があります。また、最大リトライ回数と Dead Letter Queue (最終的に配信不能なイベントの退避先) の設計も要ります。Stripe の開発者ドキュメント (2026 年 10 月時点) では本番環境の再送は最大 3 日間、Slack の Events API の説明 (2026 年 10 月時点) では再送は最大 3 回 (ほぼすぐ、1 分後、5 分後) です。