題幹與適用場景
訂單、使用者偏好或庫存服務需要在多個 Region 提供本地讀寫。請比較 DynamoDB Global Tables 的 MREC（多區域最終一致）和 MRSC（多區域強一致），說明寫入路由、衝突處理、故障切換、容量與恢復方案。題目考察資料一致性與營運邊界，不是把資料庫簡單複製到另一地區。
Global Tables 是託管的多區域、多活複製能力，任一副本都能讀寫。MREC 是預設模式，變更非同步傳播；同一 item 在不同 Region 近同時修改時，DynamoDB 以 item 粒度的內部時間戳執行 last-writer-wins。MRSC 在寫入成功前同步複製到至少另一個 Region，強一致讀取可在任一副本取得最新值，但必須恰好部署三個 Region（三個副本，或兩個副本加一個 witness）。
面試官考察點
高品質回答會先把業務不變量拆成 item、分割鍵與跨 item 交易，再依 RPO、寫入延遲與讀取一致性選擇模式。面試官會追問「最後寫入者」是否會靜默覆蓋業務狀態、MRSC 的三 Region 限制、MREC 交易的跨區可見性，以及區域隔離後的回流順序。
只回答「開啟多區域複製」不夠，還要說明請求應存取本地 Region endpoint、如何避免雙寫同一 item、如何監控 ReplicationLatency、如何處理刪除標記、重試和重複事件。
回答前需要釐清的問題
業務不變量與衝突形狀
確認訂單狀態是否允許回退、庫存是否必須線性一致、同一 item 是否可能被多個 Region 同時修改。若欄位可獨立合併，可拆成不同 item 或帶版本的子記錄；若必須跨欄位原子更新，要評估 MREC 的交易只在呼叫 Region 內原子、不會以交易單元跨區複製的限制。
RPO、延遲與區域數量
詢問可接受的 RPO、P99 寫入延遲、故障切換時間和合規 Region。MREC 可在任意可用 Region 建立副本並通常在一秒內傳播；MRSC 以部分寫入延遲換取跨區強讀與零 RPO 目標，但固定需要三個 Region。
寫入歸屬與恢復策略
明確是多活寫入，還是每個租戶有 home Region、其他 Region 只讀。若業務不能接受 LWW，應用 IAM 或路由策略限制寫入 Region，並在恢復時定義誰擁有衝突裁決權，而非讓複製層替業務決定。
30 秒回答框架
「我先按業務不變量選擇模式：庫存扣減和跨區強讀需要 MRSC，接受短暫陳舊且更重視本地寫入延遲則使用預設 MREC。MREC 採非同步複製和 item 粒度 LWW，因此我會讓同一訂單或租戶固定到 home Region，並用條件寫入、冪等鍵和明確版本防止重複更新；無法合併的狀態不依賴 LWW。所有請求存取本地 endpoint，跨區故障時切換應用流量，而不是讓客戶端跨區呼叫。監控 ReplicationLatency、複製失敗和條件寫入失敗，恢復後按版本、事件記錄和業務規則重播並稽核。」
分步驟深入解答
第一步：選擇一致性模式
MREC 是預設、可部署在任意數量 Region，副本之間最終一致，適合使用者偏好、目錄和可接受短暫陳舊的讀模型。MRSC 會在寫入成功前同步複製到至少另一個 Region，任一副本的強一致讀都能看到最新值；它要求恰好三個 Region，且不支援交易操作。模式在建立時確定，不能混用，也不能事後切換。
第二步：定義寫入拓撲
每個應用優先存取所在 Region 的 DynamoDB endpoint。多活寫入只有在業務能處理並發衝突時才開放；訂單、庫存等強約束物件可採用 home-Region 寫入、其他 Region 讀，或把狀態拆成按租戶/訂單歸屬的單寫分割。跨 Region 直接呼叫會放大延遲和故障面，流量切換應由應用入口或路由層完成。
第三步：在 MREC 中約束衝突
MREC 對同一 item 的近同時更新使用內部時間戳的 LWW，所有副本最終收斂，但被淘汰的業務變更不會自動進入補償流程。使用條件表達式檢查版本，寫入攜帶冪等請求 ID；不可覆蓋的狀態保存追加事件或衝突記錄。刪除也要有明確 tombstone 或狀態欄位，避免舊副本更新重新「復活」已刪除物件。
第四步：處理交易與重試
MREC 的 TransactWriteItems 只在發起 Region 內原子，複製到其他 Region 時可能暫時看到部分結果，因此不能把跨區讀當成交易提交確認。客戶端重試要區分條件失敗、限流和複製延遲，使用有上限的指數退避與冪等鍵。MRSC 不支援交易操作，跨 item 不變量需要重新建模或由服務層協調。
第五步：規劃故障切換與恢復
監控複製延遲、複製錯誤、條件寫入失敗、請求 Region 和業務版本。Region 隔離時，將入口流量切到健康 Region；若使用 MREC，先暫停受衝突影響的寫入或切換租戶 home Region，記錄切換時間和最後可見版本。恢復後按事件記錄、版本和業務規則校驗收斂結果，不能僅以「所有副本最終相同」判斷庫存或訂單正確。
第六步：容量、安全與治理
每個副本都要評估讀寫容量、自動擴縮容和限額；新增副本會繼承來源 Region 的容量設定，建立後再獨立調整。啟用每個副本的刪除保護，使用 IAM 限制寫入 Region 和表操作，KMS 金鑰權限失效會停止相應複製。多帳號模型支援 MREC，不適用於 MRSC，治理方案要把帳戶、Region 和稽核責任寫清楚。
第七步：驗證與演練
用兩個 Region 並發寫同一 item、條件寫入重試、網路分區、刪除與遲到更新、複製延遲尖峰、入口切換和恢復回流做演練。驗證副本最終收斂、業務補償事件完整、冪等重播不重複扣庫存，並將 ReplicationLatency 與衝突計數關聯到請求 ID。壓測要涵蓋真實 Region 距離和容量模式，不能用單機延遲推斷跨區表現。
高品質示範回答
我會先按不變量選模式。需要跨 Region 強一致讀、零 RPO 目標的關鍵資料才考慮 MRSC，並接受它必須恰好三個 Region、寫入延遲較高且不支援交易的限制；一般目錄或偏好資料使用 MREC。MREC 的非同步複製和 item 粒度 LWW 不能替業務合併衝突，所以訂單與庫存採租戶或訂單 home Region 單寫、條件表達式、版本號與冪等鍵；可合併欄位拆成獨立 item，無法合併的變更寫入衝突事件。
應用只存取本地 endpoint，入口層負責 Region 故障切換。監控 ReplicationLatency、複製失敗、條件寫入失敗和版本差異，限流與複製延遲使用有限退避。故障恢復時先凍結受影響寫入，按事件記錄和業務規則校驗收斂結果，再逐步放開流量。容量、刪除保護、IAM 和 KMS 權限按每個副本稽核，並用並發寫、分區、遲到刪除和重複重播演練證明方案成立。
常見錯誤
- 錯誤表現： 看到 Global Tables 就預設使用多活寫入。→ 失敗原因： MREC 的 LWW 可能丟掉不可合併的業務變更。→ 修正方法： 固定寫入歸屬，或明確設計版本、事件和補償。
- 錯誤表現： 把 MREC 的跨區交易當成全域原子。→ 失敗原因： 交易只在呼叫 Region 內原子，其他副本可能暫時看到部分結果。→ 修正方法： 重新建模跨區不變量，使用事件和冪等協調。
- 錯誤表現： 只在延遲超時後盲目切換 Region。→ 失敗原因： 雙寫會擴大衝突和回流風險。→ 修正方法： 先暫停或限定寫入，記錄版本，再按租戶或業務邊界切換。
- 錯誤表現： 認為副本收斂就等於庫存正確。→ 失敗原因： LWW 只解決複製衝突，不理解業務語義。→ 修正方法： 用條件寫入、事件記錄、補償任務和稽核驗證業務結果。
追問及應對
追問一：什麼時候選 MRSC？
當跨 Region 的強一致讀和零 RPO 比寫入延遲、Region 選擇自由度更重要時選擇 MRSC。它要求恰好三個 Region（可含一個 witness），並且不支援交易；若業務依賴任意數量副本或跨帳戶模型，應重新評估 MREC 與服務層協調。
追問二：LWW 覆蓋了庫存扣減怎麼辦？
不要依賴 LWW 恢復數量。為扣減使用條件表達式和版本，按商品或庫存分片固定寫入歸屬；將每次扣減寫入冪等事件，衝突偵測任務比較事件序列並生成補償或人工佇列。讀取庫存時同時檢查版本和可見時間。
追問三：MREC 複製延遲升高時怎麼處理？
告警按來源 Region、目標 Region 和業務影響分組，先限制跨 Region 寫入或切換到 home Region，避免繼續製造衝突。客戶端重試要有上限，恢復後核對版本、遲到事件和刪除標記，再逐步恢復多活。ReplicationLatency 只能說明傳播時間，不能替代業務正確性檢查。
追問四：如何測試區域故障後的回流？
演練入口切換、舊 Region 恢復、雙端請求重播和遲到刪除。記錄每個請求的 Region、版本和冪等 ID，驗證舊 Region 不會以陳舊版本覆蓋新狀態，衝突事件可追溯，補償任務可重複執行。演練結果應包含 RPO、RTO、衝突數和人工介入量。
追問五：為什麼不能混用 MREC 和 MRSC 副本？
一致性模式屬於整張 Global Table 的建立設定，副本不能採用不同模式，也不能在建立後切換。若需求改變，應規劃新表、資料遷移和雙寫/回放窗口，並先驗證容量、權限、客戶端相容性和回滾路徑。