題目與適用場景
你的 B2B SaaS 透過 Webhook 把帳單、權限或訂單事件傳給客戶。客戶常因端點逾時、回傳 5xx 或部署失誤而漏處理事件，支援團隊只能手動查日誌。請判斷是否應提供客戶可用的事件重播控制台，並說明 MVP、指標與邊界。
這是一道產品與 integrations 面試題。公開的 integrations 面試題把重播處理、冪等、退避與客戶可見健康面板列為回答要點；Stripe 文件說明事件可能重複且無序，失敗會自動重試，Dashboard 與 CLI 也提供不同的手動重試期限；GitHub 文件同樣把失敗投遞的重新傳送列為 Webhook 能力的一部分。
面試官考察重點
面試官要聽到你把「客戶想要一個按鈕」拆成問題規模、風險、價值與可交付範圍。強回答會區分自動重試與人工重播、訊息到達與業務成功、原始事件與新的投遞嘗試，並說明誰能重播、可以重播多久，以及如何避免重複副作用。
普通回答只說「做一個重試按鈕」。強回答會提出事件保留、權限、稽核、限流、冪等提示、失敗原因與成功標準，並說明何時不該做通用重播，而應先提供查詢 API、對帳或人工支援工具。
回答前需要釐清的問題
- 客戶要恢復的是「未送達事件」，還是要把已送達事件再次送給新端點？後者需要不同的權限與資料保留策略。
- 事件是否包含個人資料、支付資料或租戶機密？這會決定遮罩、加密、匯出與操作稽核要求。
- 目前自動重試覆蓋多久、失敗率和支援工單占比是多少？沒有基線就無法證明控制台創造價值。
- 客戶端是否已用事件 ID 做冪等？如果沒有，產品必須明確提醒重播可能再次觸發副作用。
30 秒回答框架
「我會先驗證失敗投遞的規模、客戶損失與支援成本，再決定是否做。若價值成立，我會先做只針對失敗事件的重播：保存不可變載荷和投遞結果，限制租戶管理員在保留期限內操作，執行限流、權限和稽核，並把每次重播視為新的投遞嘗試。指標看恢復成功率、重複副作用、支援工單和儲存成本；若資料敏感或客戶端沒有冪等，我會先提供對帳和人工核准，而不是開放任意重播。」
分步驟深入解答
先畫出現況鏈路：事件產生、簽名、投遞、客戶回傳狀態、自動重試、最終失敗。Stripe 公開行為顯示，生產環境會進行指數退避重試，Dashboard 手動重試窗口可到事件建立後 15 天，CLI 可到 30 天；這些數字只能作為競品參考，不能直接變成你的產品承諾。失敗事件要記錄端點、狀態碼、回應時間、最後一次嘗試和下一步動作。
再做價值判斷。若失敗事件很少、客戶能透過拉取 API 自行補償、重播會造成高額重複扣款，先做查詢與對帳更穩妥。若失敗集中在部署窗口，且支援人員反覆執行同一個恢復動作，控制台能降低恢復時間和支援成本。成功標準應同時包含恢復成功率、重複業務操作率、每個租戶的重播量和資料保留成本。
MVP 只允許重播「最終失敗且仍在保留期內」的事件。事件載荷保持不可變；按鈕建立新的 delivery attempt，帶原事件 ID、attempt ID、操作者、原因和時間。簽名、時間戳與重播標記的具體格式要和既有協定相容，不能讓客戶誤以為這是首次傳送。對敏感載荷，預設遮蔽正文，只給狀態和事件 ID，必要時走再次驗證。
冪等與順序必須明確處理。Stripe 明確不保證事件順序，也提醒端點可能收到同一事件多次，因此產品應在介面和文件要求按事件 ID 去重，並提示「重播不會撤銷已發生的業務副作用」。如果客戶需要補齊中間事件，提供按時間範圍篩選和逐一確認，避免一次重播整段歷史。
安全和成本是發布門檻：僅租戶管理員或特定權限可操作；每租戶和每端點設定速率上限；重複點擊使用冪等鍵；稽核日誌記錄操作者、事件、目標端點和結果；保留期限、加密與刪除策略要和隱私政策一致。批次重播應排隊並可取消，避免把恢復動作變成新的流量洪峰。
替代方案有三種。第一，繼續依賴自動重試和支援團隊手動操作，開發成本最低但恢復慢且不可規模化。第二，只開放事件查詢與拉取 API，把補償邏輯交給客戶，適合有成熟工程團隊的客戶。第三，做完整事件倉庫和任意時間範圍回放，能力最強但儲存、合規與誤操作風險最高。MVP 選擇失敗事件重播，只有指標證明客戶確實需要歷史回放時才擴大範圍。
高品質示範回答
我不會把它定義成「要不要加一個按鈕」，而會先看失敗投遞的後果。假設失敗主要發生在客戶發布期間，支援團隊每週都要人工確認並重新傳送，且事件載荷可以按租戶加密保存，我會做一個受限 MVP。第一版只展示最終失敗事件，保存不可變載荷、狀態碼和最近嘗試；租戶管理員在 15 天的預設保留窗口內發起重播，每次操作都要有權限、原因、限流與稽核記錄。重播建立新的投遞嘗試，不改變原事件 ID，並明確要求客戶按事件 ID 冪等。
我會同時保留自動重試，因為手動重播不能取代正常投遞。指標包括失敗事件恢復率、重播後的重複副作用、支援工單解決時間、每租戶重播量和儲存成本。若重複扣款或隱私風險上升，我會先收緊到人工核准或只開放對帳 API；若恢復率和支援成本都改善，再考慮批次重播與更長保留期。
常見錯誤
- 錯誤表現 → 把重播當作再次觸發業務；失敗原因 → 客戶可能已處理成功但回應遺失；修正方法 → 將投遞嘗試與業務事件分開，要求事件 ID 冪等。
- 錯誤表現 → 允許使用者編輯歷史載荷後直接傳送；失敗原因 → 破壞簽名、稽核和事件事實；修正方法 → 原始載荷唯讀，測試變體進入隔離的沙盒流程。
- 錯誤表現 → 預設永久保存所有 Webhook 正文；失敗原因 → 放大隱私、合規與儲存成本；修正方法 → 設定租戶級保留、加密、刪除和遮罩策略。
- 錯誤表現 → 用「重播次數」作為唯一成功指標；失敗原因 → 重播越多可能表示系統越不可靠；修正方法 → 結合恢復率、重複副作用、支援成本與端點健康度。
追問及應對
如果客戶要求重播 90 天前的支付事件，你會改什麼？
先驗證是否仍有合法保留依據，以及原始載荷是否包含支付或個人資料。若沒有長期保留必要性，我會提供事件 ID、目前資源查詢和對帳結果，不直接恢復正文。若業務確實需要 90 天恢復，則採用分層儲存、租戶授權、再次核准和更嚴格稽核，並把長期儲存成本計入方案或用量。
如果重播後客戶發生重複扣款，誰負責？
產品不能用免責聲明取代控制。介面應顯示事件可能已成功、要求客戶端冪等，並對高風險事件預設關閉自助重播或要求再次確認。服務端按事件 ID 和 attempt ID 記錄，提供預覽、速率限制和取消排隊任務；責任邊界寫入協議，同時保留可調查的稽核鏈。
如果一次端點故障影響一百萬個事件，如何避免恢復造成新事故？
先暫停自動重播，按端點健康度和錯誤類型分批恢復。佇列設定每租戶配額、指數退避、並發上限和熔斷；先發送小樣本，觀察 2xx、延遲、重複副作用與下游佇列深度，再逐步放量。控制台展示預計排隊量和取消入口，支援團隊可在異常時停止批次。
為什麼不直接提供任意時間範圍的全量回放？
任意回放把查詢、合規和業務補償混成一個危險操作。除非已有穩定事件倉庫、版本化載荷、權限模型與客戶端冪等基礎，否則先解決最終失敗事件的恢復閉環。產品路線應由失敗分布、客戶價值與安全證據推動，而不是由功能完整度推動。