您的結帳端點有 400ms 的 P95。剖析顯示 70% 是來自資料庫讀取。
您新增了一個讀取副本，並將所有 SELECT 查詢都指向它。P95 降低到 90ms。團隊為此慶祝。
兩小時後，支援工單湧入。客戶更新他們的運送地址，但在確認螢幕上看到的是舊的地址。一位客戶因為「訂單已存在」的檢查讀取了過期數據，錯過了重複訂單而付費了兩次。
這是設定：
• 主要 → 處理所有寫入，複製延遲約200毫秒
• 副本 → 處理100%的讀取
• 受影響的流程 → 偏好更新，訂單去重，付款單一性
副本正確地按照設計運作。那就是問題所在。
你該怎麼做？
A) 讀寫一致性：用戶寫入後，將其讀取導向主副本一段短時間內。
B) 同步複製：讓主副本等待副本確認後才確認寫入。
C) 監控副本延遲+重試：檢測延遲是否超過閾值，並回退至主副本。
D) 將關鍵讀取導向主副本：副本僅服務非關鍵讀取，如分析。
全部四種都是實際運行的真實模式。只有一種能解決過期讀問題而不損害你剛交付的性能優勢。
選擇一個（A、B、C 或 D），並告訴我原因。詳細分析在評論中，包括哪個答案是高級工程師陷阱。
如果你的團隊曾經添加過一個讀副本並花了一週時間調試過期數據，請與他們分享這個。
放下你的答案 👇