題干與適用場景
使用者要求刪除個人資料，但系統同時保留營運資料、分析資料與災備副本。部分資料已被聚合，部分下游由第三方託管。請說明請求驗證、影響範圍發現、刪除傳播、備份處理、異常恢復與對外回覆。
題目考察資料血緣、非同步工作流、冪等性、保留策略與證據鏈。法律適用範圍需要由隱私與法務確認，工程方案不能自行擴大或縮小例外。
面試官考察點
面試官會看你是否把「刪除請求已接收」、「活躍系統已刪除」、「備份已超出使用範圍」與「所有豁免有記錄」分別定義。歐盟委員會、EDPB 與 ICO 都強調刪除權存在例外，且備份不能被繼續使用；工程上必須能說明範圍與完成狀態。
高品質回答會先建立資料目錄與使用者識別碼映射，再用版本化刪除事件驅動各儲存完成刪除或隔離，最後用獨立查詢驗證。只執行一條 SQL DELETE 無法覆蓋湖倉、快取、索引、快照與第三方副本。
回答前需要澄清的問題
- 請求者如何完成帳戶級驗證，代理請求與誤刪如何防止？
- 哪些欄位屬於個人資料，哪些聚合結果已不可重新識別？
- 是否存在法律保留、財務留檔或爭議處理例外？
- 資料目錄是否記錄每個下游、快照、備份與第三方處理者？
- 對外承諾是立即刪除、在期限內完成，還是先讓資料「超出使用範圍」？
30 秒回答框架
「我先驗證請求並建立不可變的 deletion case，再透過資料目錄解析使用者識別碼與所有處理系統。工作流發布帶版本與冪等鍵的刪除事件，各下游回報狀態；活躍資料刪除後，備份按保留計畫隔離並禁止恢復使用。法律保留與不可逆匿名化單獨記錄。最後用抽樣查詢、墓碑清單、下游確認與稽核日誌證明完成範圍，失敗任務可安全重試。」
分步驟深入解答
第一步：建立資料目錄與刪除範圍
為使用者維護統一的 subject key 映射，例如帳戶 ID、租戶 ID、事件中的 pseudonymous ID 與第三方映射。資料目錄記錄來源、處理目的、保留期限、下游表格、檔案、索引、快取、快照、備份與處理者。
先凍結新增處理，避免刪除期間繼續產生同一主體的資料。對每個資產定義動作：實體刪除、欄位清除、不可逆匿名化、阻斷存取或法律保留，並記錄依據。
第二步：建立冪等刪除工作流
請求服務完成身分確認後產生 caseId、subjectId、策略版本與唯一 requestKey。透過交易式 outbox 發布刪除事件，消費者以 caseId + assetId 做冪等。
{
"type": "SubjectErasureRequested",
"caseId": "erase_20260729_001",
"subjectId": "user_123",
"policyVersion": "2026-07",
"requestKey": "user_123:20260729:001"
}每個消費者先寫狀態再執行可重試動作，或使用帶冪等約束的順序；不能因重複事件誤刪新帳戶，或把成功狀態覆寫成失敗。
第三步：處理不同儲存層
OLTP 先刪除或標記不可恢復的 tombstone；事件匯流排保留最小必要的處理記錄，阻止舊事件重新物化主體資料。資料湖與資料倉儲要更新分割區、表格、SCD、物化檢視與快照；不可變檔案可用刪除清單、重寫任務或支援刪除語義的表格格式處理。
搜尋索引、快取、反向 ETL 與第三方處理者需要獨立確認，不能把「主庫已刪」當成全域完成。聚合結果只有在無法合理重新識別且策略允許時才可保留，否則要重算或扣除該主體貢獻。
第四步：處理備份與法律保留
先判斷例外：法律義務、訴訟保全、公共利益研究等可能要求保留，但必須由授權策略決定並記錄範圍、期限與複核人。對沒有例外的備份，不能繼續用於恢復生產或分析；若無法即時覆寫，應隔離、加密、禁止讀取，並在輪換時刪除。
對外狀態要寫清活躍系統、備份與第三方副本的時間表，不聲稱「一鍵完成」已抹除所有歷史媒介。
第五步：驗證、觀測與對帳
為每個資產保存狀態、attempt、最後錯誤、刪除證明摘要與完成時間。獨立驗證器根據目錄產生查詢：活躍表無主體記錄、索引無命中、快照不再服務舊資料、下游確認已消費事件、備份處於 beyond-use 狀態。
指標至少包括待處理 case 數、各資產延遲、重試率、永久失敗數、豁免數量、第三方確認率與驗證抽樣失敗率。完成通知應引用範圍與例外，不是只回傳一個布林值。
高品質示範回答
「我會先把刪除請求變成可稽核的 case。驗證成功後產生 subject key、策略版本與唯一 request key，從資料目錄展開 OLTP、事件流、湖倉、資料倉儲、BI、索引、快取、備份與處理者。交易式 outbox 發布帶 caseId 的刪除事件，每個資產以 caseId+assetId 冪等處理並回報狀態。
活躍資料、物化檢視與索引分別刪除或重算；聚合資料只有在不可合理重新識別且政策允許時保留。備份不能繼續用於恢復或分析，無法立即覆寫就隔離到 beyond-use 狀態並按輪換計畫清除。法律保留單獨審批、限時與複核。最後用目錄驅動的獨立查詢、下游確認與稽核摘要證明範圍，失敗任務可重試而不會誤刪新資料。」
常見錯誤
- 只刪 OLTP → 湖倉、索引、快照與第三方仍可能保留資料 → 從目錄展開所有資產並逐項回執。
- 把刪除事件當成一次性腳本 → 中途失敗後無法恢復或證明完成 → 使用冪等 case、狀態機與重試。
- 把聚合都視為匿名 → 組合維度可能重新識別主體 → 做可識別性評估或重算。
- 直接刪除備份檔案 → 破壞災備、稽核或法律保留 → 隔離、禁止使用並按策略輪換。
- 對外承諾立即徹底刪除 → 技術媒介與例外可能不支援該承諾 → 說明活躍系統、備份與例外時間表。
- 業務日誌記錄完整個人資料 → 刪除後日誌成為隱藏副本 → 日誌只保留 case、資產、結果與最小錯誤摘要。
追問及應對
追問一：刪除請求到達時，如何防止誤刪同名使用者？
要求已登入工作階段、二次確認或等價身分驗證，並使用內部不可變 subject ID，不以電郵或顯示名稱作為刪除鍵。高風險租戶可增加人工審批與通知。
追問二：事件已經進入不可變日誌怎麼辦？
日誌本身不應繼續被業務讀取；為事件建立刪除或屏蔽清單，在重播與下游物化時過濾主體。若日誌含個人欄位，應按儲存能力重寫、加密隔離或按輪換期限銷毀。
追問三：聚合報表可以永久保留嗎？
不能僅憑「聚合」下結論。評估小分組、稀疏維度與外部資料組合後的重新識別風險；無法合理識別且政策允許時才保留，否則重算、扣除或刪除。
追問四：如何證明備份中的資料已刪除？
記錄備份代次、保留期限、隔離狀態、讀取控制與輪換時間，並在輪換後做抽樣驗證。無法即時覆寫時，證明其已 beyond use，比聲稱實體位元立即消失更準確。