プロンプトとコンテキスト
この質問は、データエンジニアが1つの削除リクエストを、システム横断的で再試行可能、かつ監査可能なライフサイクルに落とし込めるかをテストします。削除とは単なるプライマリデータベースの DELETE にとどまりません。派生テーブル、キャッシュ、インデックス、イベントログ、バックアップ、およびプロセッサを含みます。ディスカバリ、アイデンティティマッピング、リテールホールド（法的保持）、冪等性、リカバリ、および完了の証明を網羅してください。
面接官がテストするポイント
優れた回答では、スコープと例外を定義した上で、オーナーシップを含むデータカタログを構築します。ワークフローは依存関係に沿って削除または匿名化のコマンドを送信し、受領確認（レシート）を待ちます。状態は、変更不可能な監査証跡とともに、requested（要求済み）、running（実行中）、verified（検証済み）、blocked（ブロック済み）を区別します。物理バックアップを即座に編集できない場合は、暗号化消去（crypto-shredding）、有効期限切れ、リストア時の分離、および再適用について説明します。
明確にすべき質問
- 個人を特定する要素は何であり、メールアドレス、デバイス、注文、匿名識別子はどのように紐付けられているか？
- どのレコードを消去する必要があり、どの請求書、不正の証拠、法的保持を一時的に残す必要があるか？
- 検索インデックス、キャッシュ、集計、イベントログ、オブジェクトストレージ、バックアップ、SaaSプロセッサは対象に含まれるか？
- 目標は物理的な削除か、不可逆な匿名化か、それとも期限内での利用停止か？
- 完了、タイムアウト、人的レビュー、ユーザーへの受領通知はどのように定義されるか？
30秒の回答フレームワーク
「システム、フィールド、オーナー、保持ルール、および削除機能をカタログ化します。各リクエストは変更不可能な削除ケースと冪等なタスクを作成します。オーケストレータは依存関係に沿って削除、匿名化、またはキー消去のコマンドを送信し、各コンシューマはスコープ、バージョン、検証サマリーを返します。失敗した場合は再試行またはエスカレーションを行います。法的保持データは例外を記録した上でアクセス凍結され、保持期間が終了した時点で削除されます。完了には、カタログのカバレッジ、受領確認、サンプリング読み取り、および監査証跡が必要です。ユーザーには内部トポロジを明かさず、正確なステータスを提供します。」
ステップごとの詳細な回答
ステップ1：データおよびアイデンティティマップの構築
テーブル、バケット、インデックス、フィールド分類、オーナー、ダウンストリームの依存関係、バックアップサイクル、プロセッサをカタログ化します。安定したユーザーIDを注文、デバイス、メール、匿名トークンにマッピングします。信頼性の高いアイデンティティ結合がなければ、完全な削除という主張の信憑性は得られません。
ステップ2：削除ポリシーの定義
レコードを直接削除、匿名化、集約保持、または法的保持に分類します。財務記録や不正の証拠は保持が必要な場合がありますが、フィールドを最小限に抑え、アクセスを制限し、法的根拠を記録します。過去のリクエストについて説明責任を維持できるよう、ポリシーをバージョニングします。
ステップ3：冪等なケースの作成
case_id、対象者ID、ポリシーバージョン、期限、およびソースを作成します。すべてのターゲットはケースIDを受け取り、重複実行時にも同一の結果を返します。requested、running、verified、blocked、failed、expired などの状態を使用します。
ステップ4：依存関係に沿った伝搬
ソースレコードを削除するかツームストーン（tombstone）を発行し、インデックス、キャッシュ、派生ウェアハウス向けのCDCコンシューマをトリガーします。バッチシステムには、後続のジョブが対象者を再作成しないよう抑制テーブル（suppression table）が必要です。サードパーティはAPIレシートまたは契約上のプロセスを通じて確認します。
ステップ5：バックアップと暗号化消去の処理
バックアップは通常、スケジュールに基づいて期限切れになります。個別の編集が不可能な場合は、リストア時のアクセスを分離し、削除マニフェストを保持して、リストア処理中に削除を再適用します。対象者ごとの暗号化キーを使用すると、キー破棄後に機密な暗号文を復元不可能にできますが、これは万能な法的ショートカットではありません。
ステップ6：成功コードにとどまらない検証
コンシューマはカウント、バージョン、パーティション、チェックサムを返します。オーケストレータはプライマリリポジトリ、インデックス、ウェアハウス、オブジェクトストレージで読み取りサンプリングを行い、キャッシュ無効化とCDCウォーターマークをチェックします。検証に失敗した場合は、ケースを完了とせず補償処理を作成します。
ステップ7：保持例外の分離
法的保持レコードは最小限のフィールドで個別に保存し、プロダクトからのクエリ対象外とします。ケースレポートには、スコープ、法的根拠、オーナー、レビュー日を含めます。保持の解除によって自動的に新しい削除タスクが作成されます。例外を恒久的なブラックリストにしてはなりません。
ステップ8：監査、アラート、および応答
監査ログには、機密なペイロードではなく、不可逆な対象者ダイジェスト、実行者、時間、ポリシーバージョン、結果を含めます。ケースの経過時間、失敗率、カタログカバレッジ、サードパーティの受領確認、リストア訓練を監視します。ユーザーには、明確な期限とともに completed、processing、または legally held のステータスを表示します。
削除ワークフローの疑似コード
case = create_case(subject, policy_version)
for target in catalog.targets(subject, policy_version):
enqueue_idempotent(case.id, target, action_for(target))
verify_samples(case)
close(case, "verified" if all_verified(case) else "blocked")トレードオフと境界
| シナリオ | 戦略 | コスト |
|---|---|---|
| プライマリおよびインデックス | ツームストーンと非同期削除 | 伝搬遅延 |
| アナリティクス集計 | 識別可能な詳細を削除して再計算 | 計算コスト |
| 長期保存バックアップ | 期限切れまたはリストア時の削除リプレイ | 行の即時消去ではない |
| 法的保持 | フィールドの最小化とアクセスの凍結 | レビューとガバナンス |
証明では、システムがどこを探索し、どのターゲットが承認し、どの例外が残っているかを網羅する必要があります。検証不可能な物理的消滅を約束するべきではありません。Google Cloud は削除を段階的なパイプラインとして説明しており、各ステージが完了するまでデータは保護されたままとなります。
ロールアウト計画と根拠
1つのユーザーデータセットを選択し、カタログ、アイデンティティマップ、プライマリデータストア、インデックス、ウェアハウスを接続します。重複メッセージ、オフラインコンシューマ、バックアップリストア、ポリシー変更を意図的に注入してテストします。欧州委員会は消去に対する法的例外を文書化しており、Google Cloud は段階的削除を文書化しています。TechInterview の公開デザイン問題では、マイクロサービス、オブジェクトストレージ、アナリティクス、バックアップ、監査証跡が挙げられています。
パイロット完了基準
カタログカバレッジが測定可能であること、すべてのターゲットにオーナーと対応機能が存在すること、反復されたリクエストが冪等であること、失敗が再試行またはエスカレーションされること、サンプリング検証で残留が検出されること、保持に根拠と期限があること、そしてユーザーの受領状態が内部状態と一致していること。
成果が本物であることを証明する方法
導入前後で、未登録データセット、完了時間、検証によって発見された残留率、再試行率、人的介入を比較します。正常系のみを測定するのではなく、オフラインコンシューマ、バックアップリストア、サードパーティのタイムアウトなどを訓練します。
よくある間違いとフォローアップ
プライマリ行のみを削除する
インデックス、キャッシュ、ウェアハウス、オブジェクトストレージから依然としてデータが返される可能性があります。カタログカバレッジとダウンストリームの受領確認を完了基準とする必要があります。
すべてのシステムに対して単一のグローバルなDELETEイベントを使用する
コンシューマごとに異なるアクションとバージョンが必要です。冪等性、受領確認、ウォーターマークがなければ、イベントの喪失や重複が発生する可能性があります。ケースIDベースのワークフローを使用してください。
バックアップが即座に消去されると主張する
多くのバックアップはスケジュールに従って期限切れになります。アクセス分離、削除マニフェスト、リストア時のリプレイ、および最終的な上書き時間について説明してください。
法的保持によってすべての削除がブロックされるのを防ぐには？
保持対象のスコープを最小限に抑え、アクセスを凍結し、根拠、オーナー、レビュー日を記録した上で、保持対象外のすべての削除を続行します。
データの再作成を防ぐには？
ソースのツームストーンまたは抑制レコードを発行します。CDCおよびバッチジョブは派生データを作成する前に削除状態を確認し、リプレイによってポリシーが再適用されます。
ユーザーが即時完了を要求した場合はどうするか？
検証済みのターゲットと、時間制限のあるバックアップやサードパーティのステップを区別し、処理ステータスと期限を返します。完了した物理消去を偽ってはなりません。