題目與適用情境
某公司把使用者資料存放在 PostgreSQL、搜尋索引、快取、僅附加事件日誌、Iceberg 資料湖、資料倉儲、第三方處理者和每日備份中。請設計一套執行已核准刪除權請求的管線。它需要解析該使用者的身份別名，處理局部失敗，防止舊事件重播或備份恢復讓資料重新出現，並產出可靠的完成證據。
假設隱私或法務服務已經驗證申請人身份、核准請求、劃定範圍、記錄適用例外，並給出策略截止時間。資料平台負責執行這項決定。這道題不要求工程師解釋法律。
策略邊界要寫清楚。GDPR 第 17 條規定刪除權，同時列出了成立條件與例外，因此已核准請求需要明確範圍。第 19 條在適用情形下涉及通知接收方。線上系統、備份和版本化資料表也有不同刪除狀態：備份資料可能在等待覆寫期間保持不可使用，已從 Iceberg 目前快照刪除的資料列仍可能位於舊快照引用的檔案中。工作流程需要表達這些狀態，不能把它們壓縮成一次資料庫回應。
高品質方案會把刪除視為一條持久、受策略約束的資料工作流程：從已核驗的主體身份出發，依據資料資產目錄和血緣產生帶版本的目標清單，對每個目標執行冪等任務，阻斷資料復活，並在所有必需目標通過驗證後才宣告完成。
面試官的評估重點
第一，候選人能否先定義執行契約。關閉帳號、業務刪除事件、限制存取和核准後的刪除請求語義不同。刪除服務需要明確核准範圍、生效分界點、策略截止時間、例外和證據要求，不能自行補寫這些決定。
第二，候選人能否在真實資料模型中找全一個人。電子郵件通常不夠。同一個人可能對應帳號 ID、租戶內 ID、裝置 ID、支付客戶 ID、客服系統身份，以及帳號合併前後的歷史識別碼。好答案會加入受控的身份解析步驟，也會處理同時屬於多個主體的共享記錄。
第三，候選人能否針對異質儲存選擇動作。行式資料庫可以硬刪除或欄位去識別；搜尋和快取需要清除；不可變物件檔案可能需要重寫；資料湖刪除會產生新快照，而舊快照仍可能引用原檔案；彙總資料需要匿名化判斷和重算策略；備份與外部處理者又有各自的完成語義。
第四，工作流程能否承受重試與故障。同步請求同時呼叫所有系統，很容易逾時並留下含義不明的局部狀態。面試官希望聽到持久狀態、冪等目標任務、有限重試、明確負責人、截止時間，以及對可重試故障、已核准保留、例外和永久能力缺口的區分。
最後，候選人能否證明資料持續保持刪除。編排任務顯示綠色只能說明呼叫結束。方案還要檢查目標中是否仍存在資料、歷史版本是否可存取、重播路徑是否會重建、備份恢復是否會復活、新增資料資產是否遺漏，以及下游是否給出確認。系統還要保留足夠且最小化的控制證據來阻止復活，同時不能讓稽核資料庫變成被刪除個人資料的新副本。
回答前要先釐清的問題
- 核准內容究竟是什麼？ 涉及哪個主體、司法轄區、資料用途、時間範圍和產品？有哪些合法保留例外？誰對最終策略決定負責？
- 主體鍵是什麼？ 是否存在穩定的內部主體 ID？需要解析哪些歷史別名、合併帳號、租戶 ID、裝置 ID 和外部處理者 ID？
- 哪些記錄由多人共享？ 訂單、對話、組織記錄、風險控管證據或財務交易可能關聯多人，也可能有核准的保留要求。怎樣刪除本人的欄位，又不破壞他人的記錄？
- 資料資產目錄是否完整？ 每個儲存是否聲明負責人、主體定位方式、刪除動作、血緣、保留行為、驗證器和恢復流程？如何發現未登記資產？
- 哪些儲存可變？ 事件日誌和物件檔案能否安全重寫？邏輯刪除後，還有哪些資料湖快照和資料倉儲歷史版本可查詢？
- 備份怎樣才算完成？ 能否選擇性重寫備份，是否必須等待自然過期，還是可以先置於不可使用狀態？舊備份恢復後如何在服務接流量前重新執行刪除？
- 分界點後還會不會進新資料？ 關閉帳號是否阻止新活動？延遲事件、CDC 重試、匯入任務或重建帳號會不會繼續使用舊識別碼？
- 資料發給過哪些處理者？ 是否有 API、工單或合約約定的確認管道？它們的目標任務達到終態前需要什麼證據？
- 截止與升級規則是什麼？ 哪些故障需要通知負責人，請求何時算逾期，誰有權核准記錄明確的例外？
- 驗證怎樣避免洩露？ 探針能否只返回計數、快照 ID 和加鹽證據，不把個人值複製進日誌？
30 秒回答架構
“我會用持久工作流程執行已核准的刪除請求。同步扇出遇到一個目標逾時就會留下含義不明的局部狀態。受控身份服務先把主體解析成不透明的內部和外部識別碼；帶版本的資料目錄和血緣圖再產生目標清單。每個轉接器冪等執行硬刪除、檔案重寫、限制使用或處理者通知。最小化抑制記錄負責攔截舊事件與備份恢復造成的資料復活。完成條件包括目標級不存在檢查、快照和備份保留證據、處理者確認及重播測試。後來發現的新資產需要重新開啟請求。”
分步深入解析
步驟一：把策略決定與管線執行分開
身份驗證和範圍審核完成後，產生不可變的請求信封。它應包含請求 ID、不透明主體引用、獲准的產品與用途範圍、分界點、截止時間、策略版本、例外引用和授權決定。原始身份證明和自由文字法務意見不要進入編排記錄簿。
使用明確狀態，例如已接收、已授權、已規劃、執行中、驗證中、已完成、部分完成、已拒絕和已逾期。狀態遷移僅附加並記錄責任主體。只有核准目標清單中的每一項都達到允許的終態，請求才能結束：已刪除、在指定過期日前不可使用、處理者已確認，或存在記錄完整的例外。
這條邊界能避免兩個危險捷徑：工程團隊不能自行斷言所有彙總都已經匿名，法務服務也不能因為工作流程已經進入佇列就標記請求完成。雙方分別提供自己負責的決定和證據。
步驟二：一次解析身份，並安全保留歷史關係
先把已驗證的人映射到穩定主體鍵，再透過受限身份圖擴展識別碼。候選邊包括目前與歷史帳號 ID、合併前帳號 ID、租戶內 ID、裝置識別碼、支付客戶 ID、CRM 聯絡人以及第三方處理者引用。
身份圖要記錄生效時間和來源。被重複使用的電子郵件或手機號碼不能作為跨時間證明兩個帳號屬於同一個人的依據。共享物件還需要欄位級規則：刪除一名參與者時，不能刪掉另一人的訂單或訊息；同時，本人的直接識別碼可能需要移除或替換。
為本次請求凍結一個身份版本。後來發現別名時，追加關係並重新產生受影響目標。任務內容只保存最小化、受存取控制的定位符。普通日誌使用請求 ID、目標 ID、計數和版本，不記錄姓名或原始電子郵件。
步驟三：依據資產目錄和血緣產生目標清單
每項可能持有主體資料的資產都應登記刪除契約：
- 負責人和升級通道；
- 主體定位符及身份命名空間；
- 資料用途和保留類別；
- 上下游血緣；
- 硬刪除、欄位去識別、檔案重寫、金鑰銷毀、限制存取或通知處理者等動作；
- 快照、歷史查詢和備份的預期行為；
- 冪等鍵和重試語義；
- 驗證查詢或探針；
- 證據格式及終態規則。
規劃器把獲准範圍、凍結身份集合、資料目錄和血緣圖連接起來，產生帶版本的清單。執行前可以審閱該清單。預計匹配數為零的目標也要列出，因為明確的零比無法解釋的缺項更安全。
目錄涵蓋率需要獨立控制。掃描雲端儲存帳號、資料倉儲、主題、儲存桶、結構描述、索引和處理者登記表，尋找未登記資產；再把執行階段存取日誌與血緣事件同目錄比對。新增下游若包含範圍內資料，應為所有未結請求產生目標任務，並按策略重新開啟已完成請求。
步驟四：用持久、冪等的工作流程執行
使用支援至少一次投遞的佇列或工作流程引擎。請求狀態機按目標和身份命名空間排程任務。轉接器的冪等鍵由請求、目標、主體定位版本和動作版本共同構成。已經完成的任務再次執行時返回同一份終態證據，不產生第二次含義不明的變更。
逐目標持久化狀態：待處理、執行中、可重試失敗、受阻、已刪除、限制使用至過期、處理者待確認、例外和驗證失敗。瞬時錯誤採用有上限的指數退避；嘗試耗盡後進入死信或受阻狀態；同時暴露給負責人和截止時間監控。某個目標故障時，已成功刪除的目標不回滾。
編排器不應跨全部儲存持有分散式交易。它更像一條只向核准終態收斂的 Saga。若發生過度去識別，需要在單獨授權下從受保護的真實來源修正，不能把「補償」理解為恢復所有已經刪除的資料。
步驟五：按儲存類別選擇刪除動作
交易式資料庫。 用穩定主體鍵和映射別名定位記錄。只屬於該主體的資料列可以硬刪除；共享或獲准保留的記錄則移除核准欄位，或用不具識別性的值替換主體關聯。按外鍵順序執行，同時驗證主表與次要資料表。
搜尋、快取、特徵與向量索引。 刪除文件和嵌入、清除快取鍵，並處理非同步索引更新。來源資料表刪除不代表舊搜尋文件或特徵向量已經消失。驗證器必須檢查對外服務層面和來源儲存。
事件日誌與原始物件儲存。 若能安全重寫，就重寫受影響分割區並排除該主體。若來源在保留期間內不可變，則登記刪除墓碑或抑制權杖，所有物化、重播、匯出和啟動路徑都必須讀取它。原始來源仍要按照獲准的限制或過期方案處理；墓碑本身不能證明已經實體刪除。
資料湖表。 視情況套用等值刪除、位置刪除或重寫受影響檔案，並記錄提交與快照 ID。目前快照查詢為零時，舊快照仍可能引用檔案。Apache Iceberg 明確說明，資料檔案要等到沒有保留快照引用後才會刪除，因此在宣告對應實體刪除階段完成前，還要追蹤快照過期與孤立檔案清理。
資料倉儲與具體化檢視表。 刪除帶主體鍵的資料列，必要時重建受影響分割區，更新具體化檢視表，並列舉複本、匯出和歷史查詢版本。具體保留期屬於部署設定，不能當成所有平台統一常數。例如 BigQuery 文件說明其時間旅行期間可設定，之後還有故障保護期；目標清單應讀取實際平台策略，並記錄舊版本何時變得不可存取。
第三方處理者。 透過對方支援的管道傳送範圍明確的請求，攜帶穩定冪等引用，並保存確認和完成狀態。GDPR 第 19 條在適用情境涉及通知接收方。如果合約提供機器確認或工單終態，寄出一封電子郵件不能作為完成證據。
步驟六：明確處理彙總、模型和匿名化
先判斷結果是否仍能識別或單獨定位該主體。假名化資料仍能透過金鑰或權杖關聯，不能因為刪掉電子郵件欄位就稱為匿名。真正匿名的彙總可以不進入刪除目標，但這個判斷需要隱私負責人核准。
對於帶鍵或小群組彙總，從允許保留的來源記錄重建受影響分割區。只有可逆指標且保留了可靠貢獻資訊時，簡單相減才安全。分位數、草圖、訓練後的嵌入和許多模型產物無法靠減一列修正，需要重算、重新訓練策略或明確核准的匿名化決定。
模型處理取決於威脅和產品契約。先刪除主體層級特徵、樣本、檢索文件、快取和評估案例。若模型本身在核准範圍內，再執行獲准的重訓或模型遺忘策略。刪除管線記錄策略決定及證據，不能承諾刪掉一筆訓練資料就自動抹除既有模型中的影響。
步驟七：防止並行、重播與恢復造成復活
維護最小化抑制登記表，以不透明主體權杖和請求分界點作為鍵。擷取與物化路徑在把舊事件寫回線上或分析儲存前查詢它。該登記表專門用於識別被刪主體，存取和保留控制應比普通日誌更嚴格。
讓刪除與並行寫入有明確順序。條件允許時按主體鍵分割區執行；否則記錄來源水位，等所有寫入方越過分界點後再做一次收尾掃描。對請求後真正發生、且獲得授權的新活動單獨決策。舊事件重播必須抑制；使用者合法建立新帳號時，可以產生新的主體世代，不必變成永久全域封鎖。
所有恢復手冊都要規定：恢復服務可讀或向下游傳送資料前，先重新套用刪除記錄簿和抑制集合，並用恢復演練驗證。ICO 指引允許某些情形下備份資料留到覆寫時，但要求其不可使用。工程含義是限制存取、恢復時重播刪除、記錄過期時間，並禁止備份資料用於日常處理。
步驟八：用獨立證據驗證完成
執行變更的轉接器可以輸出執行證據，但應由獨立驗證器決定是否完成。每個目標至少記錄：
- 目標及模式版本；
- 身份定位版本；
- 動作、嘗試和完成時間；
- 受影響的資料列、文件、物件或檔案數量；
- 目前服務層面的不存在檢查；
- 保留快照或備份狀態及預計過期時間；
- 處理者確認引用；
- 驗證器版本與結果。
探針只使用計數和不透明鍵，不把已刪除的值複製進證據庫。抽樣檢查可以補充確定性驗證，但不能取代對本次請求的確定性檢查。
端到端測試應覆蓋：同一請求提交兩次；每個目標在變更成功但確認前被中斷；重播舊事件；隔離恢復舊備份；身份合併與拆分；重建帳號；新增未登記下游表；一個處理者離線；共享記錄與明確例外。必需目標沒有驗證器或狀態未知時，完成判定必須失敗關閉。
步驟九：用可衡量義務維運系統
監控請求相對策略截止時間的完成耗時、逾期與部分完成數量、目標成功率和重試率、清單涵蓋率、未知資產、處理者確認延遲、快照及備份過期積壓、重播復活事故和恢復後刪除重套用成功率。
警示要針對工作流程狀態，不能只看任務異常。請求可能一直等待處理者確認或快照過期，期間沒有任何執行錯誤，卻已經逾期。每個受阻目標都要有負責人和升級管道；定期複核例外使用情況和異常的零匹配目標。
成本也要說明。編排開銷大致隨目標數量增加，實體工作量取決於匹配記錄和受影響檔案或分割區的位元組數。檔案重寫與快照維護可以批次執行，但不能失去逐請求可追蹤性；每個請求仍要指出哪一個共享維護任務提供了它的證據。
高品質示範回答
“我只接收已經授權的請求信封，其中包含請求 ID、不透明主體引用、獲准範圍、分界點、截止時間、策略版本和例外引用。受限身份服務把主體擴展為帶版本的內部、歷史、租戶、裝置和處理者 ID，不會把電子郵件當作跨時間的唯一主鍵。
接著，我根據資料目錄和血緣圖產生帶版本的目標清單。每個目標聲明負責人、定位方式、動作、保留行為、驗證器和證據契約。目錄涵蓋線上資料庫、索引、快取、原始事件、物件儲存、資料湖和資料倉儲表、物化產物、匯出、備份與處理者。基礎設施發現和執行階段血緣會把真實資產同目錄比對，未知儲存會阻止完成，或重新開啟受影響請求。
執行層是一套非同步狀態機，採用至少一次投遞和逐目標冪等任務。重試鍵由請求、目標、身份版本和動作版本組成。行式資料庫硬刪除主體獨有資料列，對共享或獲准保留記錄只移除核准欄位。線上索引、快取、特徵庫和向量庫在刪除後接受獨立查詢。不可變原始日誌登記抑制記錄，並按核准的限制或過期計畫處理；所有重播路徑都必須查詢抑制記錄。
對 Iceberg，我會執行資料列刪除或重寫檔案，記錄提交與快照，再追蹤舊快照過期，因為目前查詢為零不等於底層檔案已經移除。資料倉儲的複本、具體化檢視表、匯出與歷史版本也要用相同思路處理。帶鍵或小群組彙總從允許資料重建；只有隱私負責人確認真正匿名的彙總才可保留。
備份有明確終態。不能選擇性重寫時，請求會記錄「限制使用直至過期」及計畫覆寫日期。恢復環境在重新套用刪除記錄簿和抑制表前不能接流量。第三方處理者使用冪等任務，收到所需終態確認前保持待處理。
為解決併發，我會記錄源水位，並在寫入方越過分界點後做收尾掃描。延遲到達和重播的舊事件被抑制。策略允許新活動時，新帳號獲得新的主體世代，避免把重播保護變成永久封禁。
獨立驗證器逐一檢查對外服務層面、目前資料表狀態、保留快照、備份狀態和處理者證據。全部目標達到允許終態後，請求才能完成。我會測試重複投遞、變更後確認前崩潰、目標離線、舊事件重播、隔離恢復、帳號重建、身份合併、共享記錄和新發現資產。
維運指標包括截止時間達標率、部分完成與逾期數量、目錄涵蓋率、未知目標、資料復活、快照和備份過期積壓、處理者延遲及恢復後刪除重套用成功率。這樣既能形成持久證據鏈，也能避免把個人值寫進普通日誌，並讓資料管線專注執行而不越權決定法律範圍。”
常見錯誤
- 只刪除主帳號表 → 索引、分析表、匯出和處理者仍有副本 → 依據血緣產生目標清單，並驗證所有必需的服務層面和儲存面。
- 把電子郵件當成統一主體鍵 → 電子郵件會變化、可能被重複使用，也找不到合併帳號和外部身份 → 透過帶來源與時間的身份圖解析已驗證主體。
- 在請求接口裡同步呼叫全部系統 → 一次超時就留下狀態不明的局部結果，重試也不安全 → 使用持久的逐目標任務、明確狀態、冪等鍵和負責人升級。
- 把軟刪除當成刪除完成 → 特權查詢、匯出、重播或恢復仍可讀取資料 → 僅把軟刪除作為已核准的限制階段，並繼續追蹤最終動作或過期。
- 目前 Iceberg 查詢為零就宣告完成 → 保留快照可能仍引用舊檔案 → 記錄快照狀態，等待核准的過期和清理階段結束。
- 預設所有彙總都是匿名資料 → 小群組、連接鍵和假名仍可能識別或單獨定位個人 → 取得明確匿名化決定，並在需要時重建衍生產物。
- 忽略重播與恢復 → 回填或備份恢復會把資料重新寫回全部系統 → 維護最小化抑制登記，並在恢復資料可用前重新套用刪除記錄簿。
- 把原始身份值寫入稽核證據 → 稽核軌跡成為被刪資料的新副本 → 只保存不透明引用、計數、版本、狀態遷移和受限證據。
- 把“已向處理者發送請求”當成完成 → 送達並不能證明對方已經執行 → 按契約追蹤確認、終態、截止時間和升級。
- 讓變更任務自己證明成功 → 成功呼叫可能漏掉舊索引、快照或靜默空操作 → 執行獨立目標探針以及端到端重播、恢復測試。
延伸追問與應對
追問一：刪除請求影響彙總表時怎麼辦？
先對每項輸出分類。若隱私負責人確認它已經真正匿名，可以保留；假名化、帶鍵或小群組輸出仍應進入處理範圍。從允許保留的來源記錄重建受影響分割區。只有可逆彙總且貢獻資訊可靠時才能簡單相減；分位數、草圖和許多學習產物需要重算或單獨核准的策略。
追問二：怎樣阻止 Kafka 重播重新產生被刪記錄？
在衍生系統宣告完成前先寫入持久抑制記錄。所有消費者、回填、物化和啟動路徑檢查不透明主體權杖與事件分界點。記錄來源水位，等目前寫入方越過分界點後做收尾掃描。把分界點前事件重播進隔離環境，證明任何目標都沒有重新可讀。
追問三：恢復舊備份時會發生什麼？
先恢復到隔離環境。在開放流量或向下游傳送資料前，套用從備份建立後到本次恢復前記錄的所有相關刪除請求，更新抑制登記並執行目標驗證器。記錄恢復服務已套用到刪除記錄簿的最高位置。等待計畫覆寫的備份保持存取受限，不能用於日常處理。
追問四：必需資料儲存臨近截止時間仍不可用怎麼辦？
請求保持部分完成或逾期狀態，已成功目標的結果繼續保留，對不可用目標進行冪等重試。在策略截止時間前升級給目標負責人和隱私維運負責人。只有經過授權的例外才能改變目標所需終態；編排器絕不能把重試耗盡轉換成靜默成功。
追問五：刪除後如何支援重新註冊帳號？
把歷史重播保護和未來獲准活動分開。重建帳號使用新的主體世代和內部 ID。抑制登記繼續拒絕舊識別碼以及分界點之前的事件，策略控制則決定是否可以擷取新資料。身份解析不能讓新世代意外重新關聯舊衍生記錄。
追問六：加密擦除能否代替實體刪除？
只有經過驗證的儲存設計才可以。如果全部相關副本都使用主體獨有金鑰加密，銷毀金鑰可以令資料不可存取。共享金鑰、明文索引、日誌、快取、匯出、備份或殘留金鑰副本都會破壞這個結論。應把金鑰銷毀視為一個帶清單和驗證器的目標動作，不能當成通用捷徑。
追問七：怎樣知道資料目錄沒有漏項？
持續把已登記資產同雲端資源清單、資料倉儲中繼資料、主題與儲存桶清單、處理者登記以及執行階段血緣或存取事件比對。新資產處理主體資料前必須登記刪除契約。未知資產觸發涵蓋率警示，並阻止或重新開啟受影響請求。定期恢復與重播演練還能發現靜態血緣經常遺漏的路徑。