プロンプトとスコープ
あなたのB2B SaaSは、Webhookを介して顧客に請求、アクセス、または注文イベントを送信しています。顧客のエンドポイントのタイムアウト、5xxレスポンスの返却、または不具合のあるコードのデプロイによってイベントを見逃すと、サポートエンジニアが手動でログを調査することになります。顧客向けのリプレイコンソールを提供すべきかどうかを判断し、MVP、メトリクス、境界について説明してください。
これはプロダクトおよびインテグレーションに関する面接の質問です。一般的なインテグレーション面接ガイドでは、リプレイ処理、冪等性、バックオフ、顧客から確認可能な健全性ダッシュボードが有用な回答要素として扱われます。Stripeは、重複イベントや順不同イベント、自動リトライ、そしてDashboardおよびCLIにおける個別の手動リトライ期間をドキュメントで説明しています。GitHubは、Webhookワークフローの一環として失敗したWebhook配信の再配信をドキュメント化しています。
面接官が評価するポイント
面接官は、あなたが「顧客がボタンを求めている」という要求を、規模、リスク、価値、スコープに関する根拠へと転換できるかを見ています。優れた回答は、自動リトライと人間によるリプレイ、配信の成功とビジネス上の成功、不変のイベントと新しい配信試行を区別します。また、誰がリプレイを実行できるか、データがどのくらいの期間保持されるか、重複する副作用がどのように防止されるかも明示します。
不十分な回答は「リトライボタンを作る」とだけ答えます。優れた回答は、保持期間、認可、監査性、レート制限、冪等性のガイダンス、失敗理由、成功基準を提案します。また、クエリAPI、照合フロー、またはサポートツールが、汎用的なリプレイよりも安全であるケースについても説明します。
回答前の確認質問
- 顧客は未配信のイベントを復旧する必要があるのか、それとも配信済みイベントを新しいエンドポイントに送信する必要があるのか？これらは異なる権限と保持ルールを必要とします。
- ペイロードに個人データ、決済データ、またはテナントのシークレットが含まれているか？これによって、マスキング、暗号化、エクスポート、監査の要件が決まります。
- 自動リトライはどのくらいの期間実行され、失敗率はどのくらいで、サポートチケットのどれくらいの割合を占めているか？ベースラインがなければ、価値は証明されません。
- クライアントはイベントIDによって重複排除を行っているか？そうでない場合、プロダクトはリプレイによって副作用が再度発生する可能性があることを警告する必要があります。
30秒の回答フレームワーク
「機能の開発に着手する前に、配信失敗のボリューム、顧客の損失、サポートコストを測定します。価値が確かであるなら、まずは失敗したイベントのみを対象とします。不変のペイロードと配信結果を保持し、認可されたテナント管理者が保持期間内に行動できるようにし、権限とレート制限を適用し、すべてのリプレイを新しい配信試行として扱います。復旧の成功率、重複する副作用、サポートチケット、ストレージコストを測定します。ペイロードが機密情報を含む場合や、クライアントに冪等性がない場合は、任意のリプレイではなく、照合と人手による承認から始めます。」
ステップごとの回答
まず、現在の経路をマッピングします：イベント作成、署名、配信、クライアントの応答、自動リトライ、および最終的な失敗。Stripeの公開されている挙動では、ライブモードでの指数バックオフ（exponential-backoff）リトライ、イベント作成後最大15日間のDashboard再送信期間、最大30日間のCLI再送信期間が示されています。これらの数値は競合他社の参考値として扱い、自社の約束とはしないでください。失敗ごとにエンドポイント、ステータスコード、レイテンシ、最新の試行、次のアクションを保存します。
次に、プロダクトの価値を検証します。失敗が稀であり、顧客がプルAPIを通じて補填でき、リプレイが高額な重複請求を引き起こすリスクがある場合、クエリと照合の方が安全な場合があります。失敗が顧客のデプロイ時に集中し、サポートが同じ復旧作業を繰り返している場合、コンソールによって復旧時間とサポートコストを削減できます。成功基準には、復旧率、重複したビジネス操作、テナントあたりのリプレイボリューム、ストレージコストを含める必要があります。
MVPでは、保持期間内にあり、最終的に失敗したイベントのみをリプレイできるようにすべきです。イベントペイロードは不変のまま保持します。このアクションによって、元のイベントID、試行ID、操作者、理由、タイムスタンプを含む新しい配信試行が作成されます。正確な署名、タイムスタンプ、リプレイマーカーは既存のプロトコルに適合していなければならず、顧客が初回配信と誤認してはなりません。機密ペイロードの場合は、デフォルトで本文を非表示にし、ステータスとイベントIDのみを表示し、必要に応じて段階的な追加認可（step-up authorization）を行います。
冪等性と順序を明確にします。Stripeはイベントの順序は保証されず、エンドポイントが同じイベントを複数回受信する可能性があると述べているため、UIとドキュメントでイベントIDによる重複排除を要求し、リプレイはすでに発生した副作用を取り消すものではないことを警告する必要があります。顧客が欠落したシーケンスを必要とする場合は、履歴全体を一度にリプレイするのではなく、時間フィルタリングとイベントごとの確認を提供します。
セキュリティとコストはリリースの判断基準（ゲート）です。アクションをテナント管理者または専用の権限に制限し、テナント単位およびエンドポイント単位のレート制限を設定し、クリックの連打に対して冪等性を確保し、操作者、イベント、ターゲットエンドポイント、結果を監査し、保持・暗号化・削除をプライバシーポリシーに準拠させます。バッチリプレイは、復旧がトラフィック急増にならないよう、キューイングおよびキャンセル可能にする必要があります。
3つの選択肢があります。最も構築コストが低い自動リトライ＋サポート支援による復旧を維持し、低速でスケーラブルでない復旧を受け入れるか。成熟したエンジニアリングチームを持つ顧客向けにイベント検索とプルAPIを提供するか。あるいは、任意の期間のリプレイが可能な完全なイベントストアを構築するかです。これは最も高機能ですが、ストレージ、コンプライアンス、誤用のリスクが最も高くなります。まずは失敗したイベントのリプレイから始め、メトリクスが履歴リプレイの必要性を示した場合にのみ拡張します。
質の高い回答例
私はこれを「ボタンを追加すべきか？」という問いとして捉えません。配信失敗の結果から始めます。失敗が顧客のリリース時に集中し、サポートが毎週手動でそれらを検証および再送信しており、テナントスコープの暗号化されたデータ保持が許容されると仮定します。私は制約を持たせたMVPをリリースします。最初のバージョンでは、最終的に失敗したイベントを一覧表示し、不変のペイロード、ステータスコード、最新の試行を保存し、テナント管理者がデフォルトの15日間の保持期間内にリプレイを要求できるようにします。すべてのアクションには認可、理由、レート制限、監査レコードが伴います。リプレイは新しい配信試行を作成し、元のイベントIDを保持し、クライアント側での重複排除を明確に要求します。
手動リプレイは通常の配信の代替にはならないため、自動リトライはそのまま維持します。復旧率、リプレイ後の重複する副作用、サポートチケットの解決時間、テナントあたりのリプレイボリューム、ストレージコストを測定します。重複請求やプライバシーリスクが増大した場合は、機能を人手による承認や照合APIに限定します。サポートコストが下がりながら復旧率が向上した場合は、バッチリプレイや長期保持を検討します。
よくある間違い
- 間違い → リプレイを新しいビジネスコマンドとして扱う；失敗 → レスポンスが失われただけで、顧客側ではすでにイベントが処理されている可能性がある；対策 → 配信試行とビジネスイベントを分離し、イベントIDによる冪等性を必須とする。
- 間違い → ユーザーが過去のペイロードを編集して直接送信できるようにする；失敗 → 署名、監査性、イベントの真正性が損なわれる；対策 → 原本は読み取り専用のまま保持し、編集されたテスト用バリアントはサンドボックス内に隔離する。
- 間違い → すべてのWebhookボディを永続的に保持する；失敗 → プライバシー、コンプライアンス、ストレージコストが無制限に増大する；対策 → テナントレベルの保持、暗号化、削除、マスキングを定義する。
- 間違い → リプレイ回数だけを成功メトリクスとして使用する；失敗 → リプレイの増加は、配信システムの信頼性の低さを示している可能性がある；対策 → 復旧、重複する副作用、サポートコスト、エンドポイントの健全性を組み合わせて評価する。
フォローアップの質問と回答
顧客から90日前の決済イベントをリプレイしたいと求められた場合、何が変わりますか？
まず、正当な保持の法的根拠があるか、ペイロードに決済データや個人データが含まれているかを確認します。長期保持が正当化されない場合は、本文を復元するのではなく、イベントID、最新のリソース照会、および照合結果を提供します。ビジネス上どうしても90日間の復旧が必要な場合は、階層型ストレージ、テナント認可、段階的な追加承認、厳格な監査、および長期ストレージを反映したプランや従量課金を利用します。
リプレイによって重複請求が発生した場合、誰が責任を負いますか？
プロダクトの統制を免責事項だけで代替することはできません。UIでイベントがすでに成功している可能性があることを明示し、クライアントの冪等性を必須とし、高リスクなイベントタイプではセルフサービスのリプレイを無効化するか確認を要求する必要があります。サービス側ではイベントIDと試行IDを記録し、プレビュー、レート制限、キューに入ったジョブのキャンセルを提供し、監査可能なチェーンを維持しつつ、契約によって責任を定義します。
100万件のイベントに影響を与えた障害から、二次障害を起こさずに復旧するにはどうすればよいですか？
自動リプレイを一時停止し、エンドポイントの健全性とエラー分類ごとにバッチ単位で復旧します。テナントごとのクォータ、指数バックオフ（exponential backoff）、同時実行数の上限、サーキットブレーカーを適用します。まず小さなサンプルを送信し、2xxの割合、レイテンシ、重複する副作用、下流のキューの深さを観察した上で、段階的に引き上げます。シグナルが悪化した際にサポートがバッチを停止できるよう、キューの予測とキャンセルアクションを表示します。
なぜ最初から任意の完全な履歴リプレイを提供しないのですか？
任意のリプレイは、検索、コンプライアンス、ビジネス上の補填を危険なアクションへと統合してしまいます。プロダクトに永続的なイベントストア、バージョン管理されたペイロード、権限管理、クライアントの冪等性がすでに備わっていない限り、まずは最終失敗の復旧ループを完成させるべきです。ロードマップの拡張は、機能の網羅性ではなく、失敗の分布、顧客価値、セキュリティの根拠に基づいて行われるべきです。