先定義失敗邊界，再設計重試
企業自動化很少是一個單純的函式呼叫。常見流程可能先從 CRM 讀取資料，建立 ERP 訂單，再寄出通知、更新 LINE 對話狀態，最後將結果寫回資料平台。任何一步都可能成功、失敗或逾時；更麻煩的是，逾時只代表呼叫端沒有收到結果，不代表對方沒有完成處理。如果系統在這種情況下從頭重跑，就可能建立重複訂單、寄出兩封通知，或讓兩套系統出現互相矛盾的狀態。
因此，第一步不是設定重試次數，而是畫出每個外部副作用及其提交點。資料查詢通常可以安全重做；建立訂單、扣庫存、發送訊息與觸發付款則需要額外保護。每個流程執行應有穩定的流程識別碼，每個步驟也要有獨立狀態，例如尚未開始、執行中、完成、失敗、結果不明與已補償。尤其要保留結果不明這個狀態，因為把網路逾時直接當成失敗，往往正是重複副作用的來源。
重試策略也應依錯誤類型決定。短暫斷線、限流或服務暫時不可用，可以採退避與抖動後重試；欄位驗證失敗、權限不足或商業規則衝突，則不應靠重試解決。若下游狀態不明，應先以原始識別碼查詢結果，再決定是否重新送出，而不是立即重放請求。
檢查點要保存可恢復的事實
檢查點的目的不是記錄一行完成訊息，而是讓另一個工作程序在不了解先前記憶體狀態的情況下，仍能從正確位置繼續。好的檢查點通常位於具商業意義的邊界，例如資料已驗證、ERP 訂單已建立、附件已上傳或通知已排入寄送佇列。粒度太粗會讓重跑範圍過大；粒度太細則增加資料庫寫入、狀態管理與清理成本。選擇原則是：若重做某一步可能昂貴、緩慢或產生外部副作用，就值得在前後建立清楚的狀態。
每筆檢查點至少應能回答以下問題：
- 執行身分：這是哪一個流程實例、租戶、來源事件與步驟。
- 輸入版本：本次處理使用哪一份資料或設定，避免重跑時悄悄換成新內容。
- 處理狀態：步驟是否已開始、完成、失敗、狀態不明或已補償。
- 外部結果：下游訂單編號、物件位置、訊息識別碼或可供查詢的參照。
- 診斷資訊：嘗試次數、錯誤類型、時間戳與關聯追蹤識別碼。
狀態更新與業務資料最好在同一個資料庫交易內完成。若必須在提交資料後發布事件，可使用 outbox 模式：先在同一交易寫入業務資料與待送事件，再由獨立發送器投遞。這無法保證訊息只會送達一次，但能把問題轉化為可管理的至少一次投遞，再由消費端以冪等方式吸收重複訊息。
冪等不是忽略重複，而是辨認同一意圖
冪等操作代表同一個商業意圖執行多次，最終效果仍等同執行一次。關鍵是選對冪等鍵。隨機產生的新請求編號無法阻止重跑造成重複，因為每次重跑都會被視為新操作。鍵值應來自穩定的商業身分，例如來源系統加來源訂單編號、租戶加事件編號，或流程識別碼加步驟名稱。資料庫可用唯一索引建立最後一道防線，應用程式則回傳先前已建立的結果。
對外部 API，如果對方支援冪等鍵，重試時必須沿用完全相同的鍵；如果不支援，就需要先查詢是否已有對應資源，或在本地維護請求與外部結果的對照。對訊息消費者，可建立 inbox 紀錄，在處理前以事件識別碼取得唯一權利，並讓業務更新與完成標記落在同一交易。單靠先查再寫並不安全，因為兩個工作程序可能同時查到不存在；唯一約束、條件式更新或適當的鎖才是並行環境中的真正保護。
冪等紀錄也有保存期限的取捨。保留太短，延遲重送可能穿透防護；永久保留，儲存與索引成本會持續增加。期限應依上游可能重送的最長時間、法規與稽核需求，以及商業物件的生命週期決定。若相同鍵搭配不同內容再次出現，系統應回報衝突並停止，而不是默默接受其中一份資料。
無法回滾的動作，需要補償與操作護欄
跨 ERP、CRM、雲端服務與通知平台的流程，通常無法使用單一資料庫交易。此時不要假裝所有動作都能回滾，而要為每個已提交的步驟定義補償。例如已建立的訂單可標記取消，已保留的庫存可釋放，已發出的錯誤通知則可能需要寄送更正訊息。補償是新的商業動作，不是時間倒轉，因此也必須具備冪等性、權限檢查、稽核紀錄與失敗重試。
並非所有失敗都應自動補償。若下游已進入人工審核、商品已出貨，或取消會造成更大的營運風險，流程應暫停並交由人員判斷。設計時可以為每個步驟註明可安全重做、需要查詢確認、可自動補償或必須人工處理，讓值班人員不必在事故發生時臨場猜測。
上線前，至少應驗證下列情境：
- 在每個外部呼叫之前與之後刻意中止流程，再從檢查點恢復。
- 重送同一事件，確認不會建立第二份商業物件或再次發送通知。
- 同時啟動兩個相同工作，確認唯一約束與鎖定機制能處理競爭。
- 模擬外部服務完成處理但回應遺失，確認系統會先查詢而非盲目重做。
- 讓補償本身失敗，確認它能重試、告警並保留人工介入所需的上下文。
最後，重跑入口本身也需要護欄：限制操作權限、顯示預計重做的步驟、支援試跑預覽，並要求操作者填寫原因。監控應以流程實例呈現目前狀態與最後成功點，而不只是散落的應用程式日誌。當流程橫跨多套企業系統時，整合團隊真正交付的價值，就是把這些恢復語意、資料契約與營運程序一併設計清楚。