あなたのチェックアウトエンドポイントにはP95が400msあります。プロファイリングではそのうち70%がDBの読み取りです.
あなたは読み取りレプリカを追加し、すべてのSELECTクエリをそれにポイントします。P95は90msに低下します。チームは祝います.
2時間後、サポートチケットが急増します。顧客は配送先住所を更新しますが、確認画面で古い住所を見ます。1人の顧客は重複注文のチェックが古いデータを読み取り、重複を見逃したため2回請求されました。
設定はこちらです：
• メイン → すべての書き込みを処理し、レプリケーション遅延は約200ms
• レプリカ → 読み取りの100%を処理
• 影響を受けるフロー → プロファイル更新、注文重複排除、支払いの排他性
レプリカは設計通りに正しく動作しています。それが問題です
どうしますか？
A) 読み書きの整合性：ユーザーが書き込みした後に一時的にプライマリに読み取りをルーティングする。
B) 同期複製：書き込みを確認する前にレプリカが確認するのを待ってプライマリを待つ。
C) レプリカの遅延監視＋再試行：遅延が閾値を超えたときに検知してプライマリに戻る。
D) 重要な読み取りをプライマリにルーティング：レプリカは分析のような非重要な読み取りのみを提供する。
4つ全てが本番で実行されている実際のパターンです。性能の勝利を最近リリースしたものを壊さずに古い読み取り問題を解決するのは1つだけです.
1つ（A、B、C、またはD）を選んで、なぜ그렇다고説明してください。コメントに詳細な分析を含め、どの答えがシニアエンジニアの落とし穴であるかも含めて.
あなたのチームが読み取りリプレイを追加し、古いデータをデバッグするのに1週間を費やしたことがあれば、それをチームと共有してください.
あなたの答えを下に投稿してください 👇