プロンプトとスコープ
マルチリージョンのSaaSで、注文ステータス、アカウント残高、未読通知、アナリティクスを表示しています。エンジニアリング側はレイテンシとコスト削減のために全体での結果整合性（eventual consistency）を提案していますが、財務側は残高が即座に正確であることを求めています。ユーザージャーニーごとに強力な整合性（strong consistency）、結果整合性、または有界ステールネス（bounded-staleness）の読み取りを選択し、プロダクトの約束事項、SLO、性能低下（デグレード）時の状態、リリースゲートを定義してください。
これは、プロダクトマネージャーが分散システムのセマンティクスを測定可能なプロダクトポリシーに落とし込めるかをテストするものです。AWS DynamoDBは結果整合性読み取りと強力な整合性読み取りを提供し、Google Cloud Spannerは外部整合性と制御されたステールリード（stale reads）を提供します。判断はスローガンではなく、読み取り／書き込みのジャーニーに基づいて行われます。
面接官が見ているポイント
- プロダクト全体を単一のモードに固定するのではなく、ユーザーアクションとリスクによってセグメント化できているか。
- 「最新」、書き込み直後の読み取り（read-after-write）、クロスリージョン、障害時の可視性を定義できているか。
- 一貫性の選択をレイテンシ、キャパシティ、コスト、収益、信頼性のメトリクスに結び付けられているか。
- デグレード時の文言、異議申し立て対応、実験、リバーシブルなロールアウトを設計できているか。
最初に確認すべき質問
- どのデータが請求、残高、在庫、コンプライアンスに影響を与え、ステール（古いデータ）の期間による損失はどの程度か？
- ユーザーは書き込み直後で、自身の書き込み内容を読み取ることを期待しているか？どの程度の遅延（ステールネス）が許容されるか？
- どのリージョンがデータをレプリケーションしており、障害モードは読み取り専用、キューイング、非表示のいずれにできるか？
- 強力な整合性と結果整合性の読み取りにおける現在のレイテンシ、キャパシティ、コストのベースラインは何か？
- 確実性があるように見せかけるのではなく、処理中、最終更新日時、コンフリクト、再試行をプロダクト上で表示できるか？
30秒の回答フレームワーク
ジャーニーを分類し、一貫性のSLOを定義します。支払いの確定、残高の変更、在庫の引き当てには、強力なセマンティクスまたはトランザクション境界が必要です。レコメンデーション、未読数、アナリティクスには、明示的な最大許容期間を設けた結果整合性または有界ステールネス読み取りを使用できます。書き込み直後の読み取り（read-after-write）には、セッションスティッキネス、バージョン、または確定エンドポイントを使用します。選択ごとにレイテンシ、コスト、エラー体験、メトリクスを明記し、低リスクなパスからカナリアリリースを実施して、信頼性や財務のガードレールに抵触した場合はロールバックするか一貫性を強化します。
ステップ・バイ・ステップの回答
1. データベース製品ではなくアクションから始める
支払いの送信、残高の確認、プロフィールの編集、レコメンデーションの閲覧、レポートの確認などのアクションをリストアップします。書き込み担当、読み取り担当、リスク、許容される古さ、エンティティ間のアトミック性をマークします。1つのページで複数のセマンティクスを組み合わせることが可能であり、グローバルに強力な読み取りを一律適用する必要はありません。
2. ユーザーが検証可能な約束事項を作成する
専門用語を観察可能な言葉に翻訳します。「支払い確定後、残高ページには確定レスポンス内の新しい残高が表示されます」や「アナリティクスは最大15分遅れる場合があり、データの取得日時が表示されます」などです。クロスリージョンの障害時の挙動も明記します。「最終的に収束する」は即座の約束にはなりません。
3. 強力な整合性、結果整合性、有界ステールネス読み取りを選択する
強力な整合性の読み取りは、損失の大きいエラー、書き込み直後の読み取り、トランザクションの制約に適しています。結果整合性の読み取りは、再試行可能、マージ可能、低リスク、または読み取り負荷の高いコンテンツに適しています。有界ステールネスは、一定の遅延期間は許容するが安定したレイテンシが必要なレポートに適しています。AWSではDynamoDBテーブルやローカルセカンダリインデックスに対するオプションの強力な整合性読み取りがドキュメント化されていますが、グローバルセカンダリインデックスやストリームは結果整合性となります。製品名ではなく機能にこれらの制限をマッピングします。
4. 書き込み直後の読み取りとコンフリクトに対処する
書き込み後にバージョン、確定トークン、または更新日時を返し、次の読み取り時にバージョン条件を送信します。必要に応じて書き込みリージョンへルーティングします。マルチリージョンでの同時書き込みには、マージルール、人手による確認、または拒否条件が必要です。損失が許容されない限り、「Last writer wins（最後の書き込み優先）」は残高に対するプロダクトポリシーにはなり得ません。
5. デグレード時の体験とガードレールを設計する
処理中である旨、最終更新日時、再試行アクションを表示します。残高や在庫が不確実な場合は、支払いを一時停止する、次のアクションを凍結する、またはオペレーターにルーティングします。ガードレールには、請求エラー、オーバーセル、苦情、書き込み直後の読み取り失敗、P95レイテンシ、レプリケーション遅延、コストが含まれます。デグレードの判断ごとに監査証跡を保持します。
6. カナリアリリース、測定、ロールバック
低リスクなテナントやジャーニーからカナリアリリースを行い、レイテンシ、成功率、ステールネス分布、コンバージョン率、サポート問い合わせ数を比較します。ステールネスがSLOを超えたり、信頼性や財務メトリクスが悪化したりした場合は、強力な読み取りに戻す、リージョンのスコープを狭める、または書き込みを一時停止します。Spannerの外部整合性とステールリードは、強力な保証と制御された古いバージョンが共存できることを示しています。グローバルに切り替えるのではなく、ジャーニーごとに選択します。
質の高い模範解答
私ならまずジャーニーをマッピングします。支払い、残高、在庫は高リスクなトランザクションであり、強力なセマンティクスまたは明示的なトランザクション境界が必要です。レコメンデーション、未読数、アナリティクスは結果整合性とし、最大遅延時間と更新日時の表示を設けます。「保存してすぐに確認する」ケースでは、バージョンまたは確定トークンを返し、短い期間セッションを書き込みリージョンに保持します。
プロダクトの文言としては、ユーザーに何が見えるか、いつ見えるか、リージョン障害時に何が起きるかを約束します。すべてのジャーニーにレイテンシ、コスト、ステールネス、エラー率、信頼性のガードレールを設定します。低リスクなパスからカナリアリリースを実施し、レプリケーション遅延、書き込み直後の読み取り失敗、請求やオーバーセルのエラー、サポート問い合わせを監視し、しきい値を超えた場合は強力な読み取りに戻す、リスクの高い書き込みを一時停止する、またはロールバックを実行します。DynamoDBのリクエストごとの制限やSpannerの外部整合性／ステールリードのオプションが示すように、一貫性とは単一のプロダクトトグルではなく、機能の組み合わせです。
よくある失敗パターン
- ジャーニーのセグメンテーションを行わずに「全体で強力な整合性を取るのが最も安全」または「全体で結果整合性にすれば最も安価」と発言する。
- ユーザーに見える状態、古さ、障害時の文言を定義せずにデータベースのレイテンシだけを議論する。
- 書き込み直後の読み取り、リージョンルーティング、同時書き込みのコンフリクトを無視する。
- すべてのインデックス、ストリーム、マルチリージョンレプリカにおいて結果整合性を同一のものとして扱う。
- 財務、在庫、信頼性、コスト、ロールバックのガードレールが存在しない。
- ベースラインや実験設計なしに固定パーセンテージの改善を約束する。
フォローアップの質問と回答例
結果整合性が許容されるのはどのような場合ですか？
わずかな古いデータの期間が不可逆的な損失を引き起こさず、ユーザーが再試行やマージを行うことができ、ページに古さとステータスを表示できる場合です。レコメンデーション、未読数、非クリティカルなレポートは、残高よりも適している場合が多いです。
書き込み直後の読み取り（read-after-write）をプロダクトSLOとしてどのように定義しますか？
書き込み確定後、指定された時間およびリージョンスコープ内での読み取りは、少なくともそのバージョンと同等以上に新しいデータを返さなければなりません。平均レイテンシだけでなく、失敗率と最大待機時間も追跡します。
なぜすべてのページで強力な読み取りを使用しないのですか？
クロスリージョンのレイテンシ、キャパシティ、コストが増加し、障害時の可用性が低下する可能性があるためです。強力なセマンティクスは、信頼性と損失防止のためにリソースを費やす価値があるジャーニーに限定して使用します。
マルチリージョンでの結果整合性におけるコンフリクトはどのように処理すべきですか？
エンティティごとにマージ可能なフィールド、バージョン条件、および未解決ケース用の人手による確認キューを定義します。マージできない残高については、暗黙的に上書きするのではなく、拒否またはロックを行います。
ユーザーに対してステールデータをどのように説明しますか？
データの取得日時、処理中の状態、更新アクションを表示します。確実性が不可欠な場合は、支払いまたは在庫に依存する次のステップをブロックし、明確なリカバリ手段を提供します。
どのような場合に別のストレージや強一貫性データベースに移行すべきですか？
現在のモードでは、許容可能なコストで書き込み直後の読み取り、エンティティ間のアトミック性、または監査要件を満たせない場合です。まずそのギャップを定量化し、その上でローカルな強力な読み取り、トランザクション、ルーティング、マイグレーションを比較検討します。