プロンプトとコンテキスト
テナントが閉鎖された後、システムは削除リクエストを受け取ります。テナントデータはプライマリデータベース、オブジェクトストレージ、検索インデックス、キャッシュ、バックアップにまたがって存在します。削除はリクエストスレッドをブロックしてはならず、ダウンストリームのいずれかが利用できない場合でも作業を暗黙的に失ってはなりません。この面接はオーケストレーション、冪等性、リカバリー、そして「完了」状態の根拠に焦点を当てています。
面接官がテストしていること
面接官は、コンポーネントを描く前に削除セマンティクスが定義されていることを確認したいと考えています。優れた設計はデータカタログ、ステートマシン、タスクの分割、冪等性キー、リトライとデッドレター、並行制御、オブザーバビリティ、および最終的な証明をカバーします。オブジェクトストレージのドキュメントは即時削除、バージョン、およびライフサイクルルールを区別しており、レプリカと非同期削除によって、プライマリデータベースの成功はすべてのコピーが処理されたことの証明にはなりません。
最初に確認すべき質問
スコープが一つのテナント、一人のユーザー、または選択されたリソースであるかどうか、ハード削除、遅延削除、および保持ウィンドウがどのように定義されているか、バックアップが即座に消去されるかウィンドウ後に期限切れになるか、生の個人データをコピーせずにどの監査レコードを残す必要があるか、そして整合性、完了時間、スケール、およびポリシーの境界が何に適用されるかを確認してください。提供されていない法的期限を勝手に作り出してはなりません。
30秒の回答フレームワーク
次のように述べてください：「テナントデータカタログと削除ポリシーを構築し、ストレージアダプターを通じてバージョン管理された削除ジョブをオーケストレーションします。リクエストは一つの冪等なジョブを作成してすぐに返却します。キューがフェーズを駆動し、各フェーズは証跡、リトライ、および最後のエラーを記録します。検証器はプライマリデータ、派生インデックス、キャッシュ、およびポリシーで許可されたバックアップがそれぞれの状態を満たした場合にのみジョブを完了としてマークします。そうでない場合はリトライまたは人間による対応をスケジュールします。」
ステップバイステップの詳細分析
1. データカタログとポリシーを構築する
各リソースについて、テナントの所有権、場所、派生元、削除方法、保持ウィンドウ、および検証クエリを記録します。即座に削除できないバックアップやログはポリシーの例外としてマークし、有効期限、承認、および保持期間中にプロダクト読み取りへアクセス不能に保つ方法を含めます。
2. 冪等な削除ジョブを送信する
クローズフローはグローバルに一意な deletionJobId を作成し、テナントのジェネレーションまたはクロージャーイベントのバージョンを冪等性条件として使用します。APIはすぐに受理ステータスを返します。重複リクエストは同じジョブを返します。後のカタログ編集がジョブの境界を変えないように、カタログバージョンのスナップショットを永続化します。
3. 依存関係によって再試行可能な作業を分割する
まずテナント状態の書き込みを凍結または切り替え、次にプライマリレコードとオブジェクトを処理し、その後に検索インデックス、キャッシュ、および派生ファイルを処理します。各アダプターは (deletionJobId, resourceId, generation) を冪等性キーとして使用します。成功、既に存在しない、および安全に再試行可能なエラーは異なる結果が必要です。再試行不可能なエラーは人間によるリカバリーパスを備えたデッドレターキューに送られます。
4. レプリカ、バージョン、バックアップを処理する
オブジェクトストレージにはバージョン、ライフサイクルルール、およびクロスリージョンレプリカが存在する場合があります。削除APIの呼び出しが成功しても、非同期コピーが即座に消えたことの証明にはなりません。各レプリカについて、リクエスト時刻、観測されたバージョンまたは削除マーカー、および最後の確認を記録します。バックアップはその保持ポリシーに従って進め、消去が即時であるかのように装わず、有効期限切れ後に回復不能であることを検証します。
5. 検証器と完了状態を設計する
検証器はカタログに問い合わせ、プライマリ読み取り、インデックス検索、キャッシュ読み取り、およびオブジェクト一覧をチェックします。ステートマシンは少なくとも ACCEPTED、RUNNING、WAITING_RETRY、BLOCKED、VERIFIED、および FAILED を区別する必要があります。証跡と明示的なポリシー例外を持つ必須リソースのみが VERIFIED に到達できます。条件付き書き込みにより、古いリトライが新しい結果を上書きするのを防ぎます。
6. オブザーバビリティ、分離、監査を追加する
テナントおよびジョブ別に、レイテンシ、成功率、リトライ、デッドレター、ダウンストリームのスロットリング、および残存リソースを追跡します。クロステナント削除を防ぐために専用の認証情報と最小権限を使用します。監査レコードはジョブID、リソースタイプ、ポリシーバージョン、アクター、および結果サマリーのみを保持し、生データは含めません。アラートは一つのブロックされたテナントとグローバルなダウンストリーム障害を区別します。
高品質なサンプル回答
「テーブル、オブジェクトプレフィックス、インデックス、キャッシュキー、バックアップポリシーのカタログから始めます。それぞれにテナントの所有権、削除方法、検証クエリを含めます。テナントを閉鎖する際に一意な deletionJobId を書き込み、新しい書き込みを凍結してジョブをエンキューします。オーケストレーターは依存関係に従います：最初にプライマリデータとオブジェクト、次にインデックスとキャッシュ。すべてのアダプターはリソースのジェネレーションによって冪等です。レプリカとオブジェクトバージョンの証跡は記録され、バックアップは即座に消去されたと主張するのではなく保持ポリシーに従います。検証器はプライマリ、検索、キャッシュ、オブジェクト一覧を再確認し、すべての必須リソースに証跡が存在する場合にのみ VERIFIED に移行します。ダウンストリームの障害は指数バックオフを使用し、その後は名前付きオーナーを持つデッドレターパスに進みます。監査はポリシーバージョン、結果サマリー、ジョブIDを保存し、認証情報はテナントごとに分離されています。クライアントは、サポートされていない「deleted」という文字列ではなく、クエリ可能なステータスと証跡を受け取ります。」
よくある間違いと改善点
- プライマリ行のみを削除する： データカタログと派生関係を描き出し、それぞれに対して削除と検証を定義してください。
- すべてのダウンストリームを同期的に呼び出す： ジョブキューとステートマシンを使用して、リクエストのレイテンシを障害から切り離してください。
- 重複作業を例外として扱う： リソースごとの冪等性キーを定義し、既に存在しない状態と失敗を区別してください。
- 即時のバックアップ消去を約束する： 保持ウィンドウ、ライフサイクル、および検証可能な有効期限切れ状態を明示してください。
フォローアップの質問と回答
ダウンストリームが失敗し続けている場合、クライアントには何を表示すべきですか？
内部の認証情報を公開することなく、クエリ可能なジョブ状態、フェーズ、エラークラス、および次のリトライ時刻を返します。リトライ予算が尽きたら、BLOCKED または FAILED に移行し、オーナーに通知して安全な再開パスを維持します。
古いジョブが新しい書き込みを削除しないようにするにはどうすればよいですか？
書き込みを凍結するか、テナントのジェネレーションを使用します。すべての削除は作成時にキャプチャされたジェネレーションを持ち、ストレージの条件はミスマッチを拒否します。カタログとステータスの更新にもバージョン管理された条件付き書き込みを使用します。
VERIFIED が偽陽性にならないことをどのようにテストしますか？
重複メッセージ、遅延レプリカ、インデックスの再構築、キャッシュの再投入、およびバックアップの復元を注入します。シミュレートされたクエリがデータを読み取ることができる場合、検証器は未完了のままであり続け、欠けている証跡を記録しなければなりません。
監査ログ自体にテナント情報が含まれている場合はどうすればよいですか？
元に戻せないテナント参照またはハッシュ、ジョブID、ポリシーバージョン、および結果サマリーのみを保存します。アクセスを制限し、監査レコードに独自の保持ポリシーを付与します。監査は削除されたデータをコピーすることなく処理を証明するものでなければなりません。