事件傳遞、冪等性和重複處理
透過網路傳送事件會產生生產者可能無法完美觀察的結果。在伺服器接收請求之前、處理請求時或在接受事件之後但回應到達呼叫者之前，可能會發生超時。重試可以改善交付，但也可能會建立重複的行。
將交付政策視為活動合約的一部分，而不是附帶的 SDK 設定。
給每個邏輯事件一個穩定的身分
知道申請結果後，建立一個 event_id。對於代表相同結果的每次網路嘗試重複使用該識別符號。不要在重試迴圈內生成新的識別符號。
const eventId = crypto.randomUUID();
const event = {
event_id: eventId,
job_id: job.id,
status: "failed",
error_type: "provider_timeout",
attempt: job.attempt,
};
await sendWithBoundedRetry("job_completed", event);
event_id 可以檢測到重複項；它本身並不能保證儲存會拒絕每個重複項。如果業務工作流程需要一次性效果，請在擁有該效果的系統中強制執行該要求。 Telemetry 應該描述結果，而不是成為支付、權利或資料庫突變的交易協調者。
決定哪些失敗可以重試
重試臨時容量和傳輸故障，例如連線錯誤、429、502、503 和 504。當回應提供 Retry-After 時，請尊重它。使用帶有抖動的指數退避，並限制嘗試次數和總執行時間。
不要重試未更改的 400 請求。無效的 JSON、資料表名稱、欄位型別或架構需要更改生產者。替換 401 之後丟失或撤銷的憑證；在 403 之後使用具有所需範圍的金鑰。
速率限制和 API 錯誤參考 包含回應類和重試規則。
預設情況下，使遙測遠離關鍵路徑
對於正常的產品和運營分析，臨時遙測故障不應將成功的客戶請求變成錯誤。限制遙測超時，報告安全診斷類別，並根據產品的故障策略繼續。
一些工作流程需要更強的交付：
- 用於提供帳單對賬的使用記錄。
- 批准的控制所需的安全審查事件。
- 不可逆轉的業務結果，沒有其他事實來源。
對於這些情況，請在業務更改時將結果寫入同一事務中的持久應用程式擁有的發件箱。工作人員可以稍後傳遞事件，同時保留其原始 event_id、發生時間和架構版本。
測量重複和丟失的交付
使用 重複事件 ID SQL 配方 查詢具有多個儲存行的識別符號。按生產者、發布和重試原因分解重複項，以便修復針對實際的交付路徑。
還監控：
- 生產者接受和拒絕的事件計數；
- 最早的未送達發件箱記錄的年齡；
- 每個邏輯事件的嘗試；
- 重試預算後永久失敗；
occurred_at和timestamp_utc之間的延遲。
對每個查詢進行重複資料刪除可以隱藏損壞的生產者。即使下游報告為每個 event_id 選擇一行，也可以保持重複率監控可見。
測試不明確的情況
演習成功，明確拒絕，交付前連線失敗，伺服器可能接受事件後超時。確認重試嘗試重用事件 ID，並且應用程式回應遵循記錄的失敗策略。