系統設計面試：如何建構不可竄改的物件保留服務？
題幹與適用場景
你要提供一個面向多個租戶的 WORM 物件服務。物件按版本保存，可設定固定保留期限，也可由 Legal Hold 無限期保護。客戶要求在保留期間拒絕刪除和覆寫，支援合規模式與治理模式，且管理員、複製任務和生命週期清理都不能繞過稽核。請說明寫入、讀取、刪除、複製、復原和稽核流程。
面試官考察點
- 是否區分物件版本、保留期限、治理模式、合規模式和 Legal Hold。
- 是否把不可變性放在儲存執行層，而不是只依賴客戶端約定。
- 是否設計權限、繞過治理、根帳戶邊界和雙人審批。
- 是否處理跨區域複製、失敗重試、刪除標記和時鐘一致性。
- 是否能證明每次策略變化和拒絕操作都可稽核。
回答前需要釐清的問題
- 保留策略按桶、前綴、物件版本還是租戶合約定義？
- 合規模式是否要求連根帳戶也不能在日期前刪除？
- Legal Hold 的發起、解除和審批主體是誰，是否需要四眼原則？
- 複製目標是否必須保留相同鎖狀態和時間，跨區域延遲上限是多少？
- 客戶需要強一致讀取、版本列表、匯出證明還是只要刪除拒絕？
30 秒回答框架
「我會把物件資料、版本索引和保留策略分成獨立但原子更新的層。寫入先產生不可變版本，策略引擎計算 retainUntil、模式和 Legal Hold 狀態，儲存刪除路徑在同一授權邊界再次檢查這些狀態。治理模式允許特定權限顯式繞過，合規模式不允許任何主體在到期前刪除；Legal Hold 沒有時間期限，只能由授權流程解除。複製攜帶版本和鎖中繼資料，稽核記錄每次寫入、刪除拒絕、繞過和策略變化，並用不可竄改日誌保存證明。」
分步驟深入解答
1. 建模物件版本與鎖狀態
物件鍵不是唯一實體，真正受保護的是 objectVersionId。版本記錄包含內容摘要、寫入時間、retainUntil、模式、Legal Hold、租戶和策略版本。簡單刪除只產生 delete marker，不應把受保護版本實體刪除；永久刪除必須明確指定版本並通過鎖檢查。
2. 設計寫入與預設保留
桶或租戶策略可以提供預設保留模式和期限，寫入請求也可宣告物件級值。伺服器驗證最大期限、時鐘來源和權限，計算後的值寫入版本中繼資料並與物件提交綁定。策略變更只影響未來版本，不能回溯縮短已有版本的保留期限。
{
"objectVersionId": "v_91c2",
"retention": {"mode": "COMPLIANCE", "retainUntil": "2027-01-01T00:00:00Z"},
"legalHold": "OFF",
"policyVersion": 18
}3. 實作刪除與覆寫閘門
刪除、覆寫、縮短期限和解除 Legal Hold 都走同一授權服務。它讀取最新版本狀態並在條件更新中驗證目前時間、模式、主體權限和 hold 狀態。治理模式需要顯式 bypass 權限和請求標記；合規模式在到期前一律拒絕，包括高權限管理員。拒絕回應包含穩定錯誤碼和稽核 ID。
4. 設計 Legal Hold 與審批
Legal Hold 獨立於期限，開啟後一直保護版本直到授權解除。解除流程要綁定案件或合約、理由、操作者、審批人和二次驗證；高風險租戶可要求雙人批准。解除後若 retainUntil 尚未到期，版本仍不可刪除，避免把 hold 當成期限覆寫開關。
5. 處理複製、復原與時鐘
複製任務傳輸內容、版本 ID、摘要和完整鎖中繼資料，目標端落盤前驗證來源簽章與策略版本。複製延遲期間來源端繼續拒絕刪除；目標端未確認鎖狀態前不能宣稱合規副本。復原使用新版本 ID，不修改舊版本的保留狀態。所有期限比較使用受控時間服務和單調稽核時間，不能依賴單台機器時鐘。
6. 做稽核與可證明性
稽核事件包括寫入、版本建立、刪除成功或拒絕、bypass、Legal Hold 變化、複製確認和策略發布。事件寫入獨立的追加式日誌，帶前序摘要或簽章鏈，並限制查詢權限。定期匯出物件版本清單、鎖狀態和稽核摘要，讓客戶能證明某版本在某時間點受保護。
高品質示範回答
「我會把版本和鎖中繼資料當作不可變事實，刪除路徑每次讀取最新狀態並執行條件檢查。物件寫入時由策略引擎計算期限、模式和 Legal Hold，並與版本提交原子綁定。治理模式允許具有明確 bypass 權限的主體顯式繞過，合規模式在到期前拒絕所有刪除；Legal Hold 只能透過有案件號、理由和審批的流程解除。複製攜帶版本、摘要和鎖中繼資料，目標確認後才算合規副本。刪除拒絕、繞過、策略變化和複製都進入追加式簽章稽核日誌，客戶可匯出版本清單和證明摘要。」
常見錯誤
- 只在 API 層檢查鎖 → 其他清理或複製路徑可繞過 → 在儲存刪除執行層複查。
- 把桶策略變更套用到舊版本 → 可能非法縮短既有期限 → 策略版本化且只影響未來寫入。
- 把 Legal Hold 當作固定期限 → 到期後自動刪除仍可能違反案件要求 → hold 獨立存在，明確解除流程。
- 治理模式預設可繞過 → 高權限誤用無法解釋 → 要求顯式權限、請求標記和審批稽核。
- 複製完成就宣稱合規 → 目標可能遺失鎖中繼資料 → 驗證目標版本和鎖狀態後再確認。
追問及應對
為什麼簡單 DELETE 可以回傳成功卻不刪除版本？
版本化物件可以把簡單 DELETE 表示為新的 delete marker，隱藏目前版本；受保護版本仍存在。永久刪除必須指定版本 ID，並在鎖閘門中被拒絕或允許。
合規模式為什麼需要更強的帳戶邊界？
它的語義是在保留日期前任何主體都不能刪除，包括根帳戶或儲存管理員。系統應把刪除能力從普通 IAM 授權中隔離，避免「超級權限」破壞合規保證。
如何證明某次刪除拒絕不是系統漏記？
讓授權決策、物件版本狀態和稽核事件使用同一請求 ID，並將事件寫入獨立追加日誌。週期性對帳刪除請求、版本清單和拒絕事件，檢測缺口後凍結高風險操作。
複製延遲時能否先刪除來源物件？
不能僅憑任務已提交就刪除。來源端鎖必須持續到目標確認內容摘要、版本 ID 和保留中繼資料；否則複製鏈路故障會造成沒有合規副本的窗口。