本文是 DynamoDB overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。

B2B SaaS 跟客戶 SLA 寫 99.99%、單 region 跑了一年遇過兩次 region-level outage、合計 downtime 已逼近 SLA 上限。team 要把核心 table 改 Global Tables active-active、首問是「multi-region write 之後資料還會一致嗎」。這個問題的答案是：不會、但有工程解法；DynamoDB Global Tables 用 LWW（Last Writer Wins）跨 region async 同步、conflict 偵測跟 reconciliation 要 application 自己加。

但 Global Tables 不只是 conflict 痛點。Disney+ 用同一個機制處理 cross-device sync（手機看一半回家用電視繼續）、Genesys 用同一個機制做 15 region B2B 客服平台的 99.999% 可用性。本文先講正向 access pattern（避免讓讀者誤以為 Global Tables 只是「跨 region 寫入會 conflict、所以痛苦」）、再展開 conflict resolution 跟 reconciliation 設計。

Workload 適配本 vendor 才繼續：DynamoDB 4 軸判讀（PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定）軸見 single-table-design-pattern 開頭 4 軸前置判讀。Global Tables 是 已選 DynamoDB 後 的拓樸決策；strong global consistency 必要的 workload 應走 Spanner / Cosmos DB strong consistency level、不是用 LWW 補。

B2B SaaS vs B2C 業務 driver 對比

Global Tables 不是預設選擇、是 業務性質 決定的工程投資。9.C24 Genesys 揭露兩條關鍵 frame — 可用性目標的業務 driver、跟每多一個 9 的 cost 指數成長。

B2C 大型網站通常 99.9% SLA、年停機 8.76 小時可接受、單 region + PITR + cross-region backup 是常見配置；改 Global Tables 邊際成本高、ROI 通常不正向。

B2B SaaS 99.95% 或 99.99% SLA 多半寫進合約、違約有具體金錢損失；Global Tables 的 N region cost 對比 SLA 違約成本通常 ROI 正向。critical 的是 合約義務 不是 技術完美。

客服平台類 99.999% 是極端可用性目標、年停機 5.26 分鐘、Genesys 撐 8000+ orgs 的客服平台、客戶停線損失極大、跨 15 region 的 active-active 是合理投資。但 不是每個 SaaS 都該追 99.999%、是 業務性質決定下限。

成本對比（9.C24 揭露）：15 region 成本約 = 1 region 的 15x（base table cost）+ 跨 region replication WCU。每多一個 9、容量規劃跟運維成本指數成長。

Scope warning（指標口徑紀律）：99.999% 是「12 個月滾動歷史值、不代表未來持續達成」（9.C24 警惕段第 1 條）。可用性是滾動指標、不是恆久承諾。引用 Genesys 99.999% 數字時要明示口徑（滾動 / customer-facing），不要寫成「DynamoDB 保證 99.999%」。

正向 access pattern：不只 conflict 議題

Global Tables 不只是 DR / availability、也是正向 access pattern 的工程方案。先建立正向用例的判讀、再進 conflict 細節。

Cross-device sync（9.C27 Disney+ 揭露）：用戶在手機看到一半、晚上回家用電視繼續、播放進度跨裝置同步。Global Tables 自然解這個 access pattern — 用戶在不同 region 登入同帳號、寫入自動同步、最終一致性可接受場景。

Global read（latency 優化）：跨地域用戶讀取就近 region 副本、latency 從 200ms 降到 < 10ms。read 比 write 多很多倍的 workload（feed / catalog / user profile）受益最大。

DR failover：region-level outage 時 application 切到 secondary region 繼續服務、RTO 通常 < 5 分鐘（DNS / routing 切換時間、不含 application 端 reconnect）。

B2C 也可能划算的場景：cross-device sync 是 user-facing experience、不是合規 / SLA driver。B2C 大規模平台（Disney+ / Spotify 類）也可能投資 Global Tables。判讀軸是「sync 體驗是否核心 UX」、不只「合約 SLA」。

核心機制：LWW conflict resolution

Global Tables 的 first-class concept：

• Multi-region active-active：每個 region 都能寫、async replication；typical replication latency < 1s 但 無 SLA
• LWW by wall clock：conflict 由 attribute aws:rep:updatetime 決定、純物理時間；不是 logical clock、不是 vector clock
• 同 region read-your-write：本 region 寫立即可讀（同 region quorum 內）、其他 region 看到要等 replication
• Capacity 獨立：每個 region 自己的 RCU/WCU、ReplicatedWriteCapacityUnits 是跨 region replication 額外 WCU、按 region 數倍計

對應 knowledge card：consistency level、rto、rpo。

設計流程

從 access pattern 分類到 reconciliation pipeline 的 6 步流程。

Step 1：access pattern 分類

把 table 中的資料分兩類：

• region-pinned data：user 主要 region（合規 / 地理 affinity）；不啟用 Global Tables、用 region-pinned cluster
• global data：跨 region read / cross-device sync；啟用 Global Tables

不是所有 table 都該上 Global Tables；user profile 跨 region 同步、但用戶交易紀錄可能該 pin 在合規 region。

Step 2：啟用 Global Tables

1aws dynamodb update-table \
2  --table-name orders \
3  --replica-updates \
4  '[{"Create": {"RegionName": "us-east-1"}}]'

加 region 後 vendor 自動 backfill；backfill 期間 capacity 雙倍（原 region + 新 region 同步流量）、要預留 capacity buffer。

Step 3：application 寫入策略

兩種寫入策略：

• home region write：每 user 固定一個 home region 寫、避免 conflict；user 跨 region 漫遊時透過 routing 仍寫 home
• nearest region write：latency 優先、user 寫就近 region；conflict 機率高、必須加 idempotency 跟 reconciliation

選擇：

Step 4：idempotency 設計

每筆 write 加 request_id 或 client_timestamp、application 端去重：

 1def write_with_idempotency(user_id, action, request_id):
 2    table.put_item(
 3        Item={
 4            "PK": f"USER#{user_id}",
 5            "SK": f"ACTION#{action}#{request_id}",
 6            "ts": datetime.utcnow().isoformat(),
 7            "request_id": request_id,
 8        },
 9        ConditionExpression="attribute_not_exists(request_id)"
10    )

ConditionExpression 在同一 region 內擋重複；跨 region eventual 仍可能 race，conflict 落到 LWW + reconciliation。

Scope warning（重要）：「加 request_id 或 client_timestamp」具體實作屬通用工程知識、9.C26 PayPay case 揭露「通知不可丟失」的需求分層、沒有 揭露具體 idempotency 實作。引用 PayPay 時要降溫成「PayPay 揭露需求分層（通知 vs 訊息）、idempotency 為通用工程實作」、不寫成「PayPay 使用 request_id」（陷阱 4：把通用工程實作寫成 case 揭露）。

Step 5：conflict detection

DynamoDB Streams 訂閱、Lambda 比較 aws:rep:updatetime 跟 application timestamp、抓出可疑 conflict 進 reconciliation queue：

 1def detect_conflict(stream_event):
 2    new_image = stream_event["dynamodb"]["NewImage"]
 3    repl_time = new_image["aws:rep:updatetime"]["S"]
 4    app_time = new_image["client_timestamp"]["S"]
 5
 6    if abs(parse(repl_time) - parse(app_time)) > timedelta(seconds=5):
 7        # 可疑 conflict、進 reconciliation
 8        sqs.send_message(
 9            QueueUrl=RECONCILIATION_QUEUE,
10            MessageBody=json.dumps(stream_event)
11        )

Scope warning：DynamoDB Streams 用法屬通用工程實作、9.C26 PayPay case 沒有 明示用 Streams、引用時要分層（PayPay 揭露需求、Streams 是工程實作的標準解）。

Step 6：reconciliation pipeline

1Conflict event → SQS queue → Lambda / human review → merge logic → write back

merge logic 視業務而定：

• 訂單金額 conflict：抓最大值（避免少收）
• 用戶設定 conflict：抓最新（user-facing 行為一致）
• watchlist conflict：union（兩裝置加的都保留）

驗證點：DR drill 演 region outage、確認 secondary region 接管後 read / write 都正常；ReplicationLatency p99 < 1s。

Rollback boundary：region 可逐個移除、但 active-active 改 active-passive 期間 application 需配合路由切換；先 application 切再移 region、不可同時做。

失敗模式

實際部署常見的 5 種失敗：

Case 1：LWW 默默吃掉 write

跨 region 同一 record concurrent update、後到的 write 因 timestamp 較大蓋過先到的；business 看到「我送出的更新沒了」、稽核 log 才發現 conflict。修法：critical write 加 ConditionExpression 比較 version attribute、conflict 時 application 端 retry + merge；不要依賴 LWW 作為 conflict 解。

Case 2：Clock skew 讓 LWW 倒置

region A 寫入 timestamp 因 NTP skew 比 region B 後寫快 200ms、結果舊資料贏。修法：依靠 application timestamp + monotonic counter、不依賴 server wall clock；critical write 用 conditional version + retry。

Scope warning：「200ms NTP skew」具體數字屬通用工程估算、case 未揭露具體 skew 範圍。

Case 3：Replication lag 撞 SLO

大 batch write 期間 replication lag 從 1s 變 30s、跨 region read 看到 30s 前資料、application 端 user 操作異常。修法：偵測 ReplicationLatency 升高時 application 端切 home region read、避免跨 region eventual read；把 replication lag 加進 SLO 監控、設 alarm。

Case 4：DR 切換後 stale data 持續 propagate

primary region outage 切到 secondary、舊 primary 恢復後仍把 outdated data 推回去、覆蓋 secondary 期間的新寫入。修法：DR runbook 含「舊 primary 恢復後人工 reconciliation 或重建」step、不可全自動 catch-up；舊 primary 恢復前先確認 replication 方向是「從 secondary catch up」而非「推舊資料回 secondary」。

Case 5：跨 region transaction 失敗

application 試圖跨 region TransactWriteItems、API 不支援跨 region transaction、原子性破裂。修法：transaction 限同 region 內、跨 region 用 saga + idempotent + reconciliation；不要把同 region 的 transaction 假設搬到跨 region。

Anti-recommendation：single-region availability 已達 99.95% + RTO 可接受 1 小時 + 預算敏感（特別 B2C 場景）→ 用 PITR + 跨 region backup 而非 Global Tables；Global Tables cost = N × single region cost 不止（對應 B2B vs B2C driver 對比）。

容量與觀測

CloudWatch metric：

• ReplicationLatency：p99 通常 < 1s、建議 SLO 設 5s alarm
• PendingReplicationCount：積壓量、batch write 期間會升高
• ReplicatedWriteCapacityUnits：跨 region replication 額外 WCU、按 region 數倍計

DynamoDB Streams + Lambda：抓 conflict event、寫進獨立 audit table；reconciliation job 從 audit table 跑、不直接動 base table。

Region-level dashboard：每個 region 獨立 capacity / latency / error rate panel；DR drill 看是否能在 RTO 內切換。

Cost monitoring：

• Global Tables cost ≈ N region × base cost + replication WCU
• 4 region 成本約 4.5x single region；15 region（Genesys 規模）約 15x
• 每多一個 region 都要重新算 ROI（軸 6 vendor crossover 的延伸）

指標口徑紀律（重要）：99.99% / 99.999% SLA 是 滾動指標 + 歷史值、不是永久承諾；引用 Genesys 99.999% 時明示「12 個月滾動 / customer-facing」、不寫成「DynamoDB 保證 99.999%」。

接回 4.20 Observability Evidence Package、9.6 容量規劃模型。

邊界與整合

Frame 5：region-pinned Global Tables 吸收合規邊界

Global Tables 不只是高可用工具、也是 合規邊界（Data Residency 拓樸）的吸收層。DynamoDB 在 vendor capability 層級支援 region-pinned replication — 每張 table 可獨立決定哪些 region 參與 replication group、部分 region 可不加入。這個 capability 同時服務三類場景：合規分離（受監管市場資料不跨境）、cost / latency 取捨（資料只在主要服務 region 同步）、災備拓樸（少數 region 純讀備援）。9.C24 Genesys 15 region 揭露的是 延遲就近接入 的 B2B SaaS 拓樸（客戶服務延遲敏感、必須在客戶所在地有 region）— case 原文沒明示合規應用、但 region-pinned capability 在 Genesys 規模下天然能容納合規市場分離、是同 capability 的 可能應用維度、不是 case 已驗證的具體實踐。

跨 vendor 對照：

為什麼 DynamoDB 在這個 frame 退化得最輕：Global Tables 的 region 開關是 attribute 級 設計（每張 table 可獨立決定哪些 region 參與）、不像 Aurora 必須整 cluster 拆。讀者要把「跨境合規 + 高可用」雙重需求兼顧時、DynamoDB 是最少結構性改造的路徑 — 但代價是 LWW conflict 跟 reconciliation 設計仍要自己做。

何時 region-pinned 而非 active-active：受監管金融 / 個資跨境禁止的市場（如 GDPR strict 條款區、中國個資法 PIPL、巴西 LGPD）— 該 region 仍開 DynamoDB table、但 不加入 Global Tables replication group、跟其他 region 完全切割。capability 設計上支援這種按 region 開關 replication 的拓樸；具體是否套用、要看 讀者自己的市場合規清單、不是把 Genesys 規模當必然證據（Genesys case 揭露的是延遲就近接入、未明示合規分離實踐）。

Disney+ vs Genesys：兩種 Global Tables 工程動機

9.C27 Disney+ 跟 9.C24 Genesys 是 Global Tables 兩種不同的工程動機：

• Disney+：cross-device sync 是 user-facing UX、watchlist + 播放進度跨裝置同步、B2C 但 sync 是 core experience
• Genesys：99.999% B2B SaaS 合約義務、15 region active-active、客服平台停線損失極大

兩個 case 都用 Global Tables、但動機完全不同 — Disney+ 是 UX driver、Genesys 是合約 driver。寫進你自己的設計時要明示自己屬哪一型，因為兩種型別的 cost 容忍度跟 conflict 容忍度完全不同。

Sibling 與 cross-link

• consistency-model-optimization — 同 region eventual / strong 取捨、本篇是跨 region 延伸
• on-demand-vs-provisioned — 多 region capacity 規劃放大、軸 5 工時釋放在 multi-region 更顯著
• partition-key-antipatterns — hot partition 跨 region 同樣存在、每個 region 的 partition 都要均勻
• single-table-design-pattern — single-table 設計在 multi-region 仍適用、access pattern 反推 PK/SK 不變
• 替代路由：global strong consistency 必要 → Spanner / Cosmos DB strong consistency level
• Migration playbook：single-region → Global Tables 屬 topology re-layout、對應 migration playbook methodology Type F
• 跟 Genesys 9.C24 互引：15 region 5 個 9 可用性的工程實踐 + B2B SaaS 業務 driver
• 跟 Disney+ 9.C27 互引：cross-device sync 作為正向 access pattern
• 跟 PayPay 9.C26 互引：揭露需求分層（通知 vs 訊息）、idempotency / Streams 為通用工程實作、PayPay 未公開揭露具體實作

本文是 Cosmos DB vendor 頁 的深度展開、也是 Strong + multi-region 互斥 議題的 SSoT 主寫位置（consistency-levels-engineering cross-link 過來、不展開）。Case anchor 是 9.C11 Minecraft Earth（AR 遊戲跨 region 寫入、5 consistency level + multi-region SLA）+ 9.C21 ASOS（Black Friday 全球零售）+ 9.C38 Toyota Connected（鏈路 SLA 拆解、跨 vendor 適用做 frame anchor）。

Cosmos DB 適用度前置判讀：本篇假設 workload 已通過 Cosmos DB 適用度四層 framing（API model 三型遷移路徑 / RU 思維轉換成本 / multi-model 差異化是否真用上 / 跨雲 hedging vs 單雲 lock-in）— 詳見 mongodb-api-vs-sql-api 開頭四層 framing、本篇不重複展開。Multi-region write + conflict resolution 是 已選 Cosmos DB 後 的拓樸決策；strong global consistency 必要的 workload 應走 Spanner 或 Cosmos DB Strong（單一 write region）、不是用 LWW 補。

問題情境：active-active 的 conflict 是必然代價

典型觸發場景：產品要 global active-active（每個 region 都能寫、低延遲）、Cosmos DB 是 AP 系統、不像 Spanner 用 quorum 強一致；跨 region 寫同一筆 document 必然有 conflict、團隊不知道「conflict 真的發生時、誰贏 / 怎麼處理 / 業務語義保不保得住」。

讀者徵兆：

• 「multi-region write 開了、user 在 A region 寫『加入購物車』、B region 寫『移除購物車』、最後哪個贏」
• 「LWW 用 timestamp 決定、client clock skew 不就破壞了嗎」
• 「conflict feed 是什麼、要不要消費」
• 「multi-region write 開了之後 consistency level 還能設 Strong 嗎」
• 「廣告寫 99.999%、為什麼實測只有 99%」

真實壓力：購物車跨 region 寫入丟失、遊戲玩家狀態跨 region 衝突回滾、IoT device 跨 region 寫 telemetry 後消失。這些事故的根因不是 bug、是 multi-region write 的 設計取捨、需要在 selection 階段就決定 conflict resolution policy。

核心機制

AP 取捨的硬約束：為什麼 Strong + multi-region write 互斥

Cosmos DB 是 AP 系統（在 partition 的情況下選 availability 跟 partition tolerance、放棄 cross-region linearizability）。multi-region write 的兩個前置條件：

• account 開啟 enableMultipleWriteLocations = true
• consistency level 不能設 Strong（multi-region write 跟 Strong 互斥、時間敏感 claim、查 最新文件）

為什麼互斥（CAP 三選二的硬約束）：

• Strong consistency 在 Cosmos DB 的實作是 quorum-based linearizable read — 確保 read 拿到最新 commit、需要 單一 write region 來保證寫入順序
• Multi-region write 是 active-active、每個 region 都能寫 — 不存在「單一 write region」、寫入是 LWW-based eventual consistency
• 兩者在技術上 不能同時成立 — 不是 Microsoft 工程選擇問題、是 distributed system 的基本限制（跟 Spanner 用 Paxos quorum + TrueTime 不同的設計路徑）

對 selection 的意義：產品要「全球都能寫」就接受 eventual consistency；產品要「全球 linearizable」就轉 Spanner / Aurora DSQL、Cosmos DB 不是替代品。把 Cosmos DB Strong 跟 Spanner external consistency 等同視之是 常見的選型誤判。

consistency-levels-engineering 的 Strong 段只 cross-link 過來、不展開 conflict resolution 細節 — 本篇是 SSoT 主寫位置。

Conflict 偵測

同一 document（partition key + id）在多 region 並發寫入、Cosmos DB 偵測為 conflict。偵測機制基於 LSN（log sequence number）、不是 timestamp — 兩個 region 對同一 document 寫入時、replication 過程比對 LSN 發現分歧、進 resolution。

三種 conflict resolution policy

LWW（Last-Writer-Wins、預設）

• 機制：用 _ts（system timestamp）或自訂 numeric property、value 大的贏
• 副作用：clock skew 在 ms 級就能讓「先寫的反而贏」、業務邏輯破洞
• 適合：純覆寫場景（如玩家位置最新值、IoT 最新讀數）— write 順序不影響業務語義

1"conflictResolutionPolicy": {
2  "mode": "LastWriterWins",
3  "conflictResolutionPath": "/customTimestamp"
4}

Custom merge stored procedure

• 機制：寫一個 JavaScript stored proc、conflict 時 Cosmos DB 呼叫、proc 回傳 merge 結果
• 適合：要保留業務語義的場景（購物車 merge = union 兩邊 items、計數器 merge = sum、status 機器 merge = 狀態圖規則）
• 風險：stored proc 在 Cosmos DB JavaScript runtime 跑、有 timeout / RU 限制；複雜 merge 邏輯難 debug

1"conflictResolutionPolicy": {
2  "mode": "Custom",
3  "conflictResolutionProcedure": "dbs/mydb/colls/mycoll/sprocs/resolveCart"
4}

Conflict feed manual reconciliation

• 機制：Cosmos DB 把 conflict 寫入 conflict feed、不自動解決、app 自行消費並 reconcile
• 適合：conflict 需要人工 / 業務流程判斷、不能 auto-resolve（如金融交易、合規場景）
• 風險：feed 不消費就累積、後續分析失準；app 需要實作 reconcile 流程

1"conflictResolutionPolicy": { "mode": "Custom" }

（沒指 procedure、conflict 全進 feed、app 用 SDK ReadConflictsAsync() / Change Feed Processor pattern 消費）

跟其他 vendor 對比

• DynamoDB Global Tables：也是 LWW、無 custom merge、無 conflict feed — 行為比 Cosmos DB 簡單但彈性少
• Spanner：用 Paxos quorum、不會有 conflict（CP 系統、可用性換一致性）— 跨 region write 需 quorum、latency 100-200ms
• Aurora Global Database：single-primary（一個 region 寫、其他 region 讀）、不是真 multi-region write、無 conflict

對應 knowledge cards：stale-read、rpo、rto。

操作流程

開啟 multi-region write

1az cosmosdb update --name mycosmos --resource-group myrg \
2  --enable-multiple-write-locations true \
3  --locations regionName=eastus failoverPriority=0 \
4  --locations regionName=westeurope failoverPriority=1

開啟後 不能直接關回、要 disable + 改 region 配置 + re-enable、有停機窗口。

設定 LWW policy（container 層）

建 container 時指定、可事後改但 conflict 行為以新 policy 為準（既有 conflict 不會重 resolve）。預設用 _ts 比較；改成 customTimestamp 時要保證 application 寫入時 用單調遞增 的 timestamp source（不能用 client clock）。

設定 custom merge

建 stored proc：

1function resolveCart(incomingItem, existingItem, isTombstone, conflictingItems) {
2  // 範例：merge 購物車 items（取 union）
3  var merged = existingItem;
4  merged.items = mergeArrays(existingItem.items, incomingItem.items);
5  merged._ts = Math.max(existingItem._ts, incomingItem._ts);
6  __.response.setBody(merged);
7}

1"conflictResolutionPolicy": {
2  "mode": "Custom",
3  "conflictResolutionProcedure": "dbs/mydb/colls/mycoll/sprocs/resolveCart"
4}

驗證：proc 內處理 timeout / exception；測 edge case（空 array / null / 並發 3+ region 寫入）。

消費 conflict feed

1// .NET SDK
2var iterator = container.GetItemQueryIterator<ConflictProperties>(
3    "SELECT * FROM c");
4while (iterator.HasMoreResults) {
5    var response = await iterator.ReadNextAsync();
6    foreach (var conflict in response) {
7        await ProcessConflict(conflict);
8    }
9}

用 Change Feed Processor pattern 把 conflict feed 當 stream 消費、寫到 reconcile queue、由業務流程處理。

驗證點

• 跨 region 並發寫測試（synthetic load）、觀察 conflict count / resolution result
• Custom merge stored proc 跑過 edge case（exception / null / 並發 3+）
• Conflict feed 不積壓（lag < 5 min）
• Region 故障時 application 仍能寫（active-active 設計、不需 manual failover）

失敗模式

Failure 1：全用 LWW + 用 server timestamp

clock skew 在 ms 級可能讓「先寫的反而贏」、業務邏輯破洞。常見徵兆：使用者反映「我明明先按確認、後來改的反而是舊的」、debug 才發現是跨 region clock skew。

修：

• 用 customTimestamp 從 application 端 monotonic source 取（如 Snowflake ID、HLC、Lamport clock）
• 或改用 custom merge stored proc、用業務邏輯而非 timestamp 決勝
• 或拆 collection、把 conflict 高的 collection 用 stored proc、低的用 LWW

Failure 2：業務語義不適合 LWW

購物車（要 union）、計數器（要 sum）、status 機器（要狀態圖）全用 LWW = 資料丟失。LWW 的設計假設是「最新 write 就是正確答案」、但很多業務語義不是覆寫關係。

修：盤點 collection 的業務語義、選對應 resolution policy：

• 覆寫關係 → LWW
• 累積關係 → custom merge stored proc（union / sum / set 合併）
• 狀態機 → custom merge stored proc（按狀態圖規則 resolve）
• 需要人工裁決 → conflict feed

Failure 3：Custom merge stored proc 沒測 edge case

proc throw exception 時 Cosmos DB 行為：conflict 留 feed、不會自動 retry。團隊以為 proc 跑了就沒事、實際 conflict 累積在 feed、後續分析失準。

修：proc 內部 try-catch、log exception、確保 任何輸入都能 return 一個合理結果（即使是 fallback 到 LWW）；定期掃 conflict feed 檢查積壓。

Failure 4：不消費 conflict feed

選 manual mode 後忘記實作 feed consumer、conflict 累積、後續分析失準。常見徵兆：feed lag metric alert、或業務反映「資料對不上」、最後發現 conflict feed 裡躺著一堆未處理的 conflict。

修：選 conflict feed mode 前先實作 consumer pipeline（Azure Function trigger on Change Feed / 自建 worker）；設 alert：feed lag > 5 min 通知。

Failure 5：期待 multi-region write 還有 Strong consistency

兩者互斥、開啟 multi-region write 後 Strong 自動 downgrade（或拒絕設定、時間敏感、查最新文件）。團隊以為「multi-region + Strong = 全球 linearizable」、底層是設計 incompatibility。

修：在 selection 階段就決定「要 active-active write 還是要 Strong」 — 兩者只能擇一。要全球 linearizable 轉 Spanner / Aurora DSQL、要 active-active 就接受 eventual / session / bounded staleness。

Failure 6：跨 region 寫入後立即同 session read 看不到

session token 沒跨 region 傳遞、看似 inconsistency 其實是 session 沒對齊。典型 anti-pattern：service A 在 region 1 寫、用 region 1 session token；service B 在 region 2 讀、沒拿到 A 的 token、看不到 A 的寫。

修：session token 隨 request 傳遞（通常進 HTTP header）；或改 account 層 Bounded staleness（提供跨 session 的 K/T bound）；見 consistency-levels-engineering 的 session token 管理段。

Failure 7：Region 故障時的 failover 邏輯誤判

multi-region write 已是 active-active、不需要 manual failover — 一個 region 掛、其他 region 自動承接寫入。但若用了 failoverPriority 配置、failover 邏輯仍要審 — priority 是 當 multi-region read 切到哪個 region 為 primary、不是 active-active 的 routing。

修：multi-region write 場景不用依賴 failoverPriority、用 Traffic Manager / Front Door 做 region routing；application 端 SDK 配置 PreferredLocations 讓 SDK 自己選 nearest region。

容量與觀測

• 必看 metric：ConflictCount、ReplicationLatency per region pair、conflict feed lag
• Conflict rate 監控：正常 < 0.01%、突增代表 hot key 或 region 同步異常
• Cost 影響：multi-region write 開啟後、寫入成本 × region 數（每個 region 都 replicate）— 3 region active-active = 3x write Request Unit cost
• 對應 9.6 容量規劃模型：multi-region write multiplier 進 sizing
• 對應 4.20 Observability Evidence Package：conflict rate 當 reliability evidence
• Alert：conflict rate > 0.1%、conflict feed lag > 5 min、cross-region replication lag > SLA

廣告 SLA vs 實測可用性鏈路拆解（本章合成 frame）

9.C11 Minecraft Earth 平台揭露的 Cosmos DB SLA：

• single-region 99.99%
• multi-region 99.999%

這是 DB 端 SLA、不是 端到端系統 SLA。真實 production 系統的可用性是鏈路乘積：

1實測可用性 = DB SLA × 網路 SLA × 應用層 SLA × 客戶端可達性

9.C38 Toyota Connected 揭露「99.99% target vs 99% 實測」段的觀察：兩個 9 的差距 不是 MongoDB / Atlas 自身問題、是 end-to-end 鏈路（車輛無線網路 / cellular tower / cloud network / event bus / microservice / DB cluster 任一環節掉都會打掉可用性）。Cosmos DB multi-region write 同模型：

• 多 region active-active 可解 DB 端可用性、但網路 / 應用層任一掉、實測仍 < 99.99%
• 廣告 99.999% 是 multi-region availability zone 級、不是 「使用者 request 成功率」

引用時必須明示：Cosmos DB multi-region 廣告 99.999% 是 DB 端、要算實測可用性必須補網路 / 應用層 SLA 乘積、Toyota case 的「99% 實測」揭露的就是這個鏈路問題、跨 vendor 都適用。

跟 conflict resolution 的關係：多 region 高可用性 買來 的代價是 conflict、conflict rate 是 reliability 的暗稅 — 廣告 SLA 不計 conflict 處理成本。production 設計要把「conflict resolution 的工程成本」加進 multi-region write 的 ROI 評估。

邊界與整合

• Sibling deep articles：consistency-levels-engineering（multi-region write 跟 Strong 互斥的 cross-link 來源）、partition-key-design（hot partition 會放大 conflict）、ru-cost-model-sizing（multi-region cost × region 數）
• 跟 Spanner vendor 對比：CP vs AP、無 conflict vs LWW / custom
• 跟 DynamoDB Global Tables 對比：兩者都 LWW、Cosmos DB 多 custom merge + conflict feed
• 跟 1.x 章節：1.11 全球分散式 OLTP 把 multi-region write 模式並陳
• Knowledge cards：stale-read / rpo / rto
• Anti-recommendation：single-region write + cross-region read replica 在大多數情況更便宜、更易推理；只有 write residency 是產品契約（合規 / latency / 業務需求）時才升 multi-region write

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 multi-region write + conflict resolution backlog 的深度展開
• 9.C11 Minecraft Earth case — multi-region 99.999% / single-region 99.99% SLA 來源
• 9.C21 ASOS case — 全球零售 multi-region 補充
• 9.C38 Toyota Connected case — 鏈路 SLA 拆解 frame anchor（跨 vendor 適用）
• consistency-levels-engineering — Strong + multi-region 互斥的 cross-link 目的地
• Stale Read 卡片 / RPO 卡片 / RTO 卡片 — 概念基底
• 官方：Cosmos DB conflict resolution / Multi-region writes

多人（或多 agent）並行開發時，如果修改集中在同一個檔案，協調成本可能抵消並行的收益。以下是一個具體案例。

v0.3.0 的 JS SDK 開發中，五張 ticket 被並行派發給五個 AI agent：flush 邏輯、離線容錯、自動攔截、頁面生命週期、rate limiting。前四個都需要修改同一個檔案 monitor.ts。

結果：

• 三個 agent 回報 branch protection hook 阻擋 src 編輯
• 兩個 agent 回報 file modified since read 拒絕 Edit（另一個 agent 正在寫同一檔案）
• PM 花了多個回合協調 commit 策略：「你先 commit」「你等他完成」「你只 git add 你的檔案」
• 最終 PM 手動合併所有 agent 的變更，做了一個統一 commit

並行派發的目標是縮短總工時。但五個 agent 改同一檔案時，協調成本抵消了並行的收益。

根因：派發粒度錯在 ticket 層而非檔案層

派發決策看的是 ticket 的獨立性——五張 ticket 描述的功能確實獨立（flush、離線、攔截、生命週期各自有清楚的邊界）。但獨立的功能不等於獨立的檔案。五個功能的修改都集中在 monitor.ts 這一個檔案上。

ticket 獨立 =/= 檔案獨立。並行安全的判斷基準應該是後者。

教訓

派發前掃描 where.files：如果多張 ticket 的目標檔案有交集，序列化派發。前一張完成並 commit 後，再派下一張。

序列的代價比衝突的代價低：五個 agent 序列執行可能需要 5 倍時間，但每個 agent 在乾淨的工作區上操作，不需要協調。五個 agent 並行但衝突，PM 的協調時間加上 agent 的等待和重試，總成本可能更高。

Worktree 隔離不是萬靈丹：git worktree 讓每個 agent 有獨立的工作目錄，避免 working tree 衝突。但如果兩個 agent 修改同一檔案的不同區段，merge 時仍需人工判斷。Worktree 解決的是「同時寫同一個 working tree」的問題，不解決「同時改同一個檔案的語意衝突」。

適用場景

這個 pattern 不限於 AI agent。人類開發者在同一個 Sprint 中被分配修改同一個檔案的不同功能時，也會遇到 merge conflict。差異在於人類可以口頭協調（「我先改完你再改」），agent 目前缺乏這個即時溝通管道。派發者（PM 或 CI 系統）需要在派發時就做好檔案衝突預判。