本文是 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 未公開揭露具體實作

本文是 PostgreSQL overview 的 implementation-layer deep article。同時是 #128 self-aware limitation 第 1 點「6 維仍可能漏類（identity / consistency / residency 三軸候選）」的 residency 軸驗證、跟 migration playbook methodology「何時不該套」段 對「政策合規驅動」是否在 methodology scope 的反思。

政策驅動的 migration 屬本 methodology 嗎

Migration playbook methodology 「何時不該套」段曾把「compliance-driven migration」歸為排除情境、後來改寫為「不在排除範圍 — 法規驅動只是 driver、資料層仍走 type A-E 之一」。本文是該改寫的 正面實證 — GDPR EU residency 強制需求驅動 single-region → multi-region rollout、本文是 政策驅動但仍走 audit + type 對映流程 的 case study。

但 reviewer D 在第三輪 audit 提出：residency 不只是 driver、本身是 cross-cutting constraint、反向約束 topology + operational + schema；該不該升 獨立 audit 軸？本文是該議題的 dogfood。

三層約束：driver / topology / contract

GDPR 對 PostgreSQL multi-region rollout 的影響在三個層次：

1. Driver layer：EU 客戶資料必須 物理上儲存在 EU（GDPR Article 44-49）— 觸發 multi-region migration 的根本理由
2. Topology layer：跨 region replication 不能 自由跨 region 複製 EU 客戶資料、必須按 GDPR scope 分區；topology 設計受合規約束
3. Contract layer：審計能 demonstrate 「EU 資料在 EU」、操作日誌 + replication evidence 必須可追溯；application + ops contract 多出合規 obligation

跑 6 維 diff dimension audit 對「single us-east → us-east + eu-west」：

6 維 audit 抓不到「Residency contract = High」這軸。用既有 6 維歸類、會走 Type F multi-axis（topology + operational + application change 多 High）+ 政策合規補強段；但這個歸類 漏掉合規對 topology / operational / application 的反向約束：

• Topology layer：6 維只 audit 「topology 是否變動」、漏 audit 「topology 範圍是否受合規約束」
• Operational layer：6 維只 audit 「operational 是否重設計」、漏 audit 「audit log / encryption / access control 是否符合合規要求」
• Application layer：6 維只 audit 「application code 是否改」、漏 audit 「資料 routing 是否符合 residency rule」

Residency 不只是 driver、是 cross-cutting constraint、會反向約束其他 3-4 維、且帶獨立工作量（合規 evidence collection / DPIA / audit prep）。

Residency axis 是否獨立：3 個論據

Yes、residency 是獨立軸：

1. 可獨立發生：原本 multi-region setup、新增「PCI 強制信用卡資料只能 us-east」、是 純 residency 變更、其他 6 維皆 Low（topology 不重設計、operational 不重設計、application 加 routing rule 即可）；但 residency 約束 routing + log 範圍
2. 驅動工作量分佈：本文 multi-region GDPR rollout 工作量分佈：
   • Topology setup（logical replication / region setup）：~25%
   • Operational redesign（HA / backup / monitoring）：~20%
   • Application routing change（region detection / data filter）：~15%
   • Residency compliance（DPIA / audit log / access control / encryption / evidence）：~40%
3. Cross-cutting nature：residency 不只影響「資料放哪」、影響：
   • Backup 可不可以 cross-region store（多數 GDPR 不允許）
   • Audit log 是否包含 EU PII（需 EU 端 log + 跨 region log filter）
   • Encryption key 是否可 cross-region share（多數情境不允許）
   • Application access logs 是否含 EU IP / user ID

No、residency 可塞 operational + driver：

• 反論：residency 是 operational 子議題、加 audit + replication scope 規則就好
• 拒絕：residency 反向約束 topology / application / operational、且帶獨立合規工作量（DPIA / cross-border transfer agreement / data subject rights）；不是單純 operational 子議題

實證：本文 migration 工作量 40% 在 compliance、確認 residency 是 獨立工作量主軸。

結構：Type F multi-axis + residency compliance 獨立段

本文結構是 Type F 為主（topology high + operational high）+ residency compliance 獨立段（不在 6 維任一個）：

11. 政策驅動的 migration 屬本 methodology 嗎（meta-reflection 開頭）
22. 三層約束：driver / topology / contract
33. Residency axis 是否獨立的論據
44. 結構 differentiator（Type F multi-axis + residency compliance 段）
55. EU residency 對 topology / operational / application 的反向約束
66. Migration 流程（含 DPIA 跟 evidence collection 階段）
77. Production 故障演練
88. Capacity / cost（含合規 audit cost）
99. 整合 / 下一步

9 章節、240-270 行。比標準 Type F 多 1 段（residency compliance）+ 1 段（meta-reflection）。

EU residency 對其他維度的反向約束

 1Residency rule → Topology constraint:
 2- EU customer data 不能 replicate to us-east
 3- Backup of EU table 不能 store in non-EU region
 4- Logical replication subscriber 在 us-east 必須 filter out EU data
 5
 6Residency rule → Operational constraint:
 7- Cross-region monitoring 不能 export EU PII to global SaaS (Datadog)
 8- Audit log 含 EU user_id 必須 store 在 EU
 9- Encryption key (KMS) 不能 share 跨 region（EU 端用 EU KMS）
10- DBA / SRE access EU data 必須 from EU jurisdiction + 記 audit trail
11
12Residency rule → Application constraint:
13- Application 必須 detect user region + route 對應 DB endpoint
14- Cross-region join / aggregate 對 EU user 必須走 EU 端 query
15- Data export feature 必須 reject 跨 region export request

每條反向約束都是 新工作量、不在 6 維 audit 內。

Migration 流程（含 DPIA + evidence collection）

10 step、跨 5 個月：

Step 1 + 9 + 10 是 residency-specific、不在既有 6 維內。

Production 故障演練

Case 1：Replication filter 漏 table、EU 資料 leak 到 us-east

徵兆：6 個月後 internal audit 發現 us-east 端 customers table 含 EU 客戶資料；replication filter 設定漏改、新加的 eu_customer_extensions table 被自動 replicate 到 us-east。

根因：PostgreSQL logical replication publication 預設 FOR ALL TABLES、新加的 table 自動納入；應該明示 FOR TABLE list... 並 GDPR review。

修法：

1. Publication 改 explicit table list：CREATE PUBLICATION xxx FOR TABLE users, orders, ...、不用 FOR ALL TABLES
2. Schema change review 加 GDPR check：每個 DDL PR 必須答「新 table 是否含 EU PII、是否該 filter」
3. Replication monitor：定期跑 SELECT * FROM pg_publication_tables 對照 expected list、漂移立刻 alert
4. Evidence collection：filter 配置 + audit log 留檔、出事 DPO 知道何時 leak

Case 2：Backup 跨 region store、合規違規

徵兆：跑 1 年後 GDPR audit 抓到 EU table 的 backup 存在 us-west S3 bucket；違反 Article 44-49 限制。

根因：pgBackRest 預設用 global S3 bucket（在 us-east-1）；EU PostgreSQL cluster backup 跑去 us-east、跨境傳輸無 transfer mechanism。

修法：

1. Per-region backup config：EU cluster 用 EU S3 bucket（eu-west-1）、寫進 pgBackRest config
2. Backup test：每月跑一次 backup restore drill、validate backup 是 from EU region
3. Bucket policy 強 enforce：EU bucket 加 aws:RequestedRegion=eu-west-1 強制 region match
4. Audit log archive 同理：log shipping 也必須 region-respect

Case 3：Monitor SaaS 收集 EU PII、合規 alert

徵兆：Datadog APM 收集了 EU customer 端 request 含 user_email 在 trace、被 DPO catch、required to delete 過去 90 天的 Datadog data。

根因：APM trace 預設收集 application context、含 PII；Datadog 是 us-east SaaS、PII 跨境到 Datadog us-east、違規。

修法：

1. APM scrub PII：application 端在 trace 前 scrub user_email / user_id 替換成 hash
2. EU-specific monitor stack：EU PostgreSQL + APM 用 Grafana on EU EKS、不送 Datadog
3. 跨 region SaaS use 必須 audit：所有外部 SaaS（Datadog / Sentry / NewRelic）必須 GDPR-friendly 配置
4. Privacy by design：log / trace 預設 scrub PII、不是 opt-in

Case 4：Cross-region query 跑 EU + US 資料、residency 違規

徵兆：BI dashboard 跑跨 region aggregation query（EU sales + US sales）、PostgreSQL FDW 從 us-east cluster query EU cluster、EU 端 server log 顯示「PII export to us-east」。

根因：開發者用 PostgreSQL Foreign Data Wrapper（FDW）方便跑跨 region query、不知道這在 GDPR 視為跨境 PII export。

修法：

1. Architecture: aggregate at edge：BI 跑 per-region aggregate、再在 BI layer compose（無 PII）；不直接跨 region join
2. FDW 限制：disable FDW from us-east → EU cluster、enforce one-way data flow
3. DBA access policy：DBA 不能直接 query EU cluster 從 us-east jumpbox
4. Query audit：production query log 跑 PII detection（regex / NER）、發現跨境 export 立即 alert

Case 5：DR drill 跨 region failover、暴露 residency assumption 失敗

徵兆：DR drill「EU 完全不可用、切到 us-east」執行後、發現 us-east 端 沒 EU 資料 — 因為一直 strict residency filter；business 端 EU 客戶 24 小時無法服務。

根因：strict GDPR residency 跟 strict DR availability 衝突 — 要 跨 region DR 就要 跨 region 持有資料、要 strict residency 就 DR 範圍受限。

修法：

1. DR strategy revision：EU 端 multi-AZ within EU、不靠跨 region；EU region 全不可用情境接受 longer RTO
2. Compliance + DR negotiation：跟 DPO / 法務談 DR 跨境 short-window 是否可接受、簽 cross-border transfer agreement
3. Backup recovery 在 EU 內：EU 端 backup 跨 AZ store、不跨 region；EU AZ 災難用 EU 另一個 AZ 重建
4. 明示 RTO trade-off：EU customer SLA 寫「regional DR 內 RTO 1 小時、global DR 24-48 小時」、residency 跟 DR 是 互斥取捨

Capacity / cost

判讀：GDPR multi-region 成本 1.5-2.5x、但合規是 必要 spend、用 cost optimization 的框架看會誤判；多數歐洲業務 7+ 年回本（避免 4% revenue fine）。

整合 / 下一步

跟 PostgreSQL → Aurora 對位

Aurora Global Database 可簡化跨 region setup、但 residency filter 仍需 application 端；不是「Aurora 就解決 GDPR」。

跟 Multi-DC MongoDB 對位

兩篇都是 multi-region rollout、但本文加合規維度；MongoDB 篇純 capacity + DR driver、本文加 residency constraint、結構不同。

跟 #128 self-aware limitation 第 1 點對位

本文驗證 residency axis 候選：

• Yes 軸獨立：reverse-constrain topology + operational + application、且帶獨立 compliance 工作量（DPIA / evidence collection / DPO sign-off）
• 作為 driver 不夠：methodology 把 residency 歸為 driver 太窄、忽略 cross-cutting constraint 性質

未來 audit 可能擴 7 維（加 residency / compliance contract）；累積 PCI / HIPAA / SOX 等不同合規 case 後再評估。

下一步議題

• Identity + Consistency + Residency 三軸候選統合：本批 3 篇分別驗證、未來累積 evidence 後考慮獨立 #129 卡 / 擴 audit 到 7-8 維
• Schrems II + new EU data transfer rules：跨大西洋資料傳輸法規變動快、playbook 半衰期短
• Data localization in China / Russia / India：類似 GDPR 但細節不同、未來 case 累積後評估

相關連結

• 上游 vendor 頁：PostgreSQL
• 平行 multi-region case：MongoDB Shard + Multi-DC
• 平行 axis 候選驗證：Vault → AWS Secrets Manager（identity 候選）/ DynamoDB Consistency Model（consistency 候選）
• Methodology：Migration playbook methodology / #128 self-aware limitation 第 1 點（residency axis 候選驗證、本文是該驗證的 dogfood）

本文是 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

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 Global Database 的實作層教學。前置閱讀建議 Aurora storage architecture（理解 storage-level replication）、Aurora cross-AZ failover RTO（對照單 region failover）。

問題情境

典型觸發場景：global SaaS / 跨地理金融服務、需要 region-level DR（us-east-1 整 region 失效時 < 5 分鐘恢復寫入）、或跨地理 read（歐洲用戶查美國 primary 延遲 100ms+ 不可接受）、但又不到「multi-region active-active write」需求。

讀者常見的具體疑問：

• 「Global Database 是 sync 還是 async？lag 多少？」
• 「Secondary region 可以寫嗎？」
• 「Region failover 流程跟 cross-AZ 一樣嗎？」
• 「跟 Aurora DSQL / Spanner / CockroachDB 怎麼選？」
• 「合規場景一定要用 Global Database 嗎？」

進一步問題：Global Database 對一般 SaaS 是合理的 DR + 跨地理 read 工具、但對 受監管產業 是反指標。9.C14 Standard Chartered 7 個受監管市場、各自獨立 Aurora cluster、不用 Global Database — 不是技術不夠、是合規要求「資料不能跨境複製」。讀者規劃 multi-region 架構時、合規維度要在技術維度之前判斷。

核心機制：跨 region async storage replication

Aurora Global Database 的 first-class concept 是 跨 region storage-level async replication。跟 logical replication / streaming replication 不同、Global Database 在 storage layer 複製、lag 上限相對穩定。

Architecture：

• Primary region：1 個 writer cluster + N read replica
• Secondary region：最多 5 個 secondary region、每 region N 個 reader-only cluster（最多 16 個 reader 含 1 個 headless）
• Storage replication：primary region 寫 storage 後 async push 到 secondary region storage、不等 ack

Write path：

1Application
2    ↓ writer endpoint (primary region only)
3Primary region compute
4    ↓ redo log
5Primary region storage (4-of-6 quorum)
6    ↓ async replication (typical < 1 秒)
7Secondary region storage

Read path：

• Secondary region 直接從 local storage 讀、不需要跨 region 拉
• Read latency 是 secondary region local latency、不是跨 region

DR 切換 RTO 跟 cross-AZ 對比：

數量級不同 — cross-AZ 是 seconds、cross-region planned 是 minutes、unplanned 是 tens of minutes。

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

跟通用 cross-region replication 差在哪：Aurora 在 storage layer 複製、lag 上限更穩定；vs PostgreSQL logical replication lag 受寫速度影響大、heavy write 期間可能秒級到分鐘級。

Step-by-step 配置

建 global cluster：

 1# Step 1：在 primary region 建 global cluster
 2aws rds create-global-cluster \
 3  --global-cluster-identifier myglobal \
 4  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:primary-cluster \
 5  --region us-east-1
 6
 7# Step 2：在 secondary region 加 reader cluster
 8aws rds create-db-cluster \
 9  --db-cluster-identifier secondary-cluster \
10  --global-cluster-identifier myglobal \
11  --engine aurora-postgresql \
12  --source-region us-east-1 \
13  --region eu-west-1
14
15# Step 3：在 secondary region 建 db instance
16aws rds create-db-instance \
17  --db-cluster-identifier secondary-cluster \
18  --db-instance-identifier secondary-reader-01 \
19  --db-instance-class db.r6g.4xlarge \
20  --engine aurora-postgresql \
21  --region eu-west-1

Application routing：

1# 寫永遠去 primary region writer endpoint
2primary:
3  url: jdbc:postgresql://primary-cluster.cluster-xxx.us-east-1.rds.amazonaws.com/mydb
4
5# read 可走 secondary region reader endpoint（靠近用戶的 region）
6secondary-eu:
7  url: jdbc:postgresql://secondary-cluster.cluster-ro-xxx.eu-west-1.rds.amazonaws.com/mydb

DR 切換（planned failover）：

1aws rds failover-global-cluster \
2  --global-cluster-identifier myglobal \
3  --target-db-cluster-identifier arn:aws:rds:eu-west-1:123:cluster:secondary-cluster

切換後 application 端要 reconfigure connection string — DNS 不自動切跨 region（vs cross-AZ failover writer endpoint 自動跟）。

Application reconfiguration 模式：

• Connection string 用 service discovery（Consul / Route53 health check）動態解析
• 或在 application config 加入 region-aware logic、failover 後切換 active region
• 不能假設 application 自動 reconnect 到新 primary region

驗證點：

• AuroraGlobalDBReplicationLag < 1 秒
• Planned failover RTO 量測（手動 trigger + heartbeat timestamp diff）
• Application 跨 region read 路徑 latency 符合預期

Rollback boundary：promote secondary 後原 primary 變 secondary、不會自動 fallback；rollback 要再做一次 failover。

故障模式 / 邊界 case

Case 1：期待 multi-region active-active write

徵兆：team 在 secondary region application 直連 secondary cluster 寫資料、收到 cannot execute INSERT in a read-only transaction 錯誤。

原因：Global Database secondary 是 reader-only、寫只能去 primary region。要 active-active write 必須改用其他服務（Aurora DSQL / Spanner / CockroachDB）。

修：

• Application 設計時明確區分 read region vs write region
• 寫操作永遠路由到 primary region、容忍跨 region write latency
• 真的需要 active-active write 才考慮 Aurora DSQL（2024-12 preview / 2025-05 GA）

Case 2：DNS 不跨 region 自動切

徵兆：手動 failover trigger 後、application 端 connection string 仍指向舊 primary region、寫操作全失敗。

原因：cross-AZ failover writer endpoint DNS 自動跟、cross-region 不會 — Global Database 切換要 application 端管 region-specific connection string。

修：

• Application 用 service discovery（Route53 / Consul / etcd）解析 active primary region
• 部署 region-aware DNS（Route53 latency-based routing + health check）
• Failover 演練要包含 application reconfiguration step、不只是 DB layer

Case 3：跨 region read 假設 strong consistency

徵兆：用戶在 primary region 寫資料、隨即在 secondary region read、看到舊資料、客訴 inconsistency。

原因：Global Database 是 async replication、< 1 秒 lag 不是 zero、read-after-write 場景仍會看到 stale data。

修：

• 用戶寫操作後短期內 read 走 primary region（read-after-write window）
• 接受最終一致性、application 端做 versioning / timestamp 比對
• 強一致性需求改 Aurora DSQL / Spanner

Case 4：Lag spike during bulk operation

徵兆：DDL 或 bulk insert 期間 cross-region lag 從 < 1 秒跳到秒級到分鐘級、secondary region read 大量 stale。

原因：Global Database 「< 1 秒」是 typical、heavy write 期間 lag 拉大。Storage-level replication 比 logical 穩定、但 不是 zero variance。

修：

• DDL 跟 bulk insert 在低峰期跑、避開跨 region read traffic
• 監測 AuroraGlobalDBReplicationLag、spike 超過閾值 trigger application 端 fallback（read 切回 primary region）
• 重要 DDL 用 pg_repack 避免長時間 lag

Case 5：合規邊界誤用 Global Database — Standard Chartered anti-pattern

徵兆：team 以為 Global Database 是受監管金融的標準 DR 解、配置完才發現監管機構不接受跨境資料複製、被迫拆掉 Global Database 重建獨立 cluster。

9.C14 Standard Chartered case 「判讀」段第 1 點原文：「7 個受監管市場代表 7 個獨立 cluster（資料不能跨境）、容量規劃變成『7 個獨立規劃 × 各自合規門檻』」。

原因：受監管市場資料 不能跨境複製（Data Residency 硬約束）、Global Database 本質上就是跨 region storage replication、配置了就違反合規。Standard Chartered 的選擇是 每市場獨立 cluster、跨市場 DR 走應用層市場切換、不靠 Global Database。

修：

• 規劃 multi-region 前先確認合規要求（資料駐留、跨境複製禁令、稽核要求）
• 合規禁止跨境複製場景：每市場獨立 cluster + cross-AZ failover 吸收 RTO（見 cross-az-failover-rto）
• 跨市場 DR 設計成 市場切換（用戶從 A 市場切到 B 市場）、不是 資料切換
• Fleet 拓樸（多市場 → 多 cluster）詳見 Aurora read replica scaling fleet 治理 SSoT

scope warning（必明示）：Standard Chartered case 未公開是 PostgreSQL 還是 MySQL、未公開具體 cost 數字、屬「相關 case study」匿名對照。引用時不能擴寫具體 engine。

Case 6：Cost trap — cross-region data transfer

徵兆：開了 Global Database 後月帳變高 50%、發現 cross-region data transfer 是主要費用、不是 instance。

原因：Aurora 跨 region replication 走 AWS 內部網路、但 cross-region data transfer 仍計費。Heavy write workload 月費可能 doubled。

修：

• 用 AuroraGlobalDBReplicatedWriteIO × per-region transfer rate 估月費
• Write-heavy workload 評估 Global Database ROI（保險、低費用版本是用 cross-region snapshot 做冷備）
• Cost 跟 RTO 一起看 — 如果接受 hours RTO、cross-region snapshot 更便宜

Case 7：FanDuel 雙峰 case 對照（避免 over-extrapolate）

如果 team 引用 9.C28 FanDuel 規劃 multi-region 部署、要明示 scope warning。

case「判讀」段第 1 點原文：「直播跟投注是兩種完全不同 SLO：直播容忍秒級延遲（用 CDN + ABR 串流）、投注必須毫秒級成交。兩個服務必須各自獨立擴容、各自獨立 SLO」。

scope warning（必明示）：

• FanDuel 5-10x 是 betting 服務的 Aurora 擴容倍數、不是 streaming（streaming 走 CDN、不走 Aurora）
• 不能壓成「Aurora 撐 5-10x」單一數字
• 案例自承：betting transaction TPS 跟 concurrent streams 未公開、不能 over-extrapolate

引用 FanDuel 規劃自家 multi-region betting workload 時、看 策略（事件型分級 + 雙 SLO 拆分 + 多層 edge）、不套用 具體數字。

跟 Aurora DSQL / Spanner / CockroachDB 的決策樹

Global Database 是 async + reader-only secondary、不是 multi-region active-active。當 active-active write 是核心需求時、要看 distributed SQL 方案。

何時選 Global Database：

• DR + 跨地理 read 是主要需求
• 寫流量集中在一個 region（單 region write 撐得住）
• 合規允許跨境複製（一般 SaaS、非受監管）
• 從 single-region Aurora 升級、不想換 engine

何時改 Aurora DSQL / Spanner / CockroachDB：

• Multi-region active-active write
• 跨 region strong consistency 是業務需求
• 跨雲 / on-prem 需求（CockroachDB）

何時不用 Global Database：

• 合規禁止跨境複製（Standard Chartered case）→ 每市場獨立 cluster
• Single-region 已滿足 DR / read 需求
• 跨 region cost 不划算（write-heavy workload）

容量與觀測

核心 metric：

1AuroraGlobalDBReplicationLag       # secondary lag、< 1 秒 typical
2AuroraGlobalDBReplicatedWriteIO    # cross-region data transfer 量
3AuroraGlobalDBProgressLag          # storage replication progress

容量上限：

• 1 primary region + 5 secondary region
• 每 secondary region 16 個 reader 含 1 個 headless（可升 writer）

Cost signal：

1月費 ≈ AuroraGlobalDBReplicatedWriteIO × per-region transfer rate
2     + secondary region instance + storage
3     + cross-region snapshot (optional)

Write 量大的 workload 月費可能 doubled（primary region + secondary region 都計費）、要在規劃時估準。

驗證 DR：

• Planned failover drill 每季一次、量測 RTO / RPO
• 受監管產業：每月一次、有合規 sign-off 記錄
• 重大版本升級前必跑一次

回路徑：9.6 容量規劃模型 cross-region cost、8.x DR playbook region-level failover decision。

邊界與整合 / 下一步

Sibling deep articles：

• Aurora storage architecture — cross-region replication 是 storage-level 延伸
• Aurora cross-AZ failover RTO — cross-AZ 跟 cross-region failover RTO 數量級對比
• Aurora read replica scaling — fleet 治理 SSoT、合規驅動 fleet 拓樸的展開

Migration playbook：

• PostgreSQL / MySQL → Aurora — 從 PostgreSQL streaming replication 跨 region 升級的差異

1.x 章節互引：

• 1.11 全球分散式 OLTP — Global Database vs distributed SQL 對比

何時不用本文：single-region OLTP、無跨 region DR / read 需求時可跳過、看 Aurora vendor overview 即可。

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Stale Read 卡片 — read-after-write 容忍度
• RPO 卡片 — DR RPO 判讀
• 9.C14 Standard Chartered — 合規驅動的 Global Database anti-pattern
• 9.C28 FanDuel — 雙 SLO 並行的 multi-region 策略對照
• Vendor 深度技術文章方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora Global Database

本文是 CockroachDB vendor overview 的 implementation-layer deep article。Overview 已界定 CockroachDB 的 multi-region 能力、本文聚焦 locality 配置怎麼解合規地理邊界 + 跨 boundary 業務邏輯需求 — 用 Hard Rock Digital 跨 8 州單一邏輯 cluster 作為 concrete framing。Replica placement 機制屬前置、見 HLC + Raft consensus、survival goal 互動見 survival goals。

問題情境：Hard Rock 的跨州 sportsbook 拓樸創新

美國 sportsbook 受 Wire Act 規範、betting data 必須在下注州內處理 → 每個營運州都要有州內運算資源。傳統路徑是「每州一個獨立 silo、each silo 一個獨立 DB cluster」、合規上沒問題、但撞牆於三個業務需求：

• 跨州統一帳戶：玩家在 NJ 跟 FL 兩州都有帳戶、登入要看到統一 portfolio
• 跨州 reporting：總公司 BI / 財務 reporting 要橫跨所有州、不能 query N 個 cluster 後再合
• 跨州欺詐偵測：同一張身分證在不同州 IP 同時下注 → 風控引擎要看 cross-state aggregated 資料

9.C41 Hard Rock Digital 跨 8 州（AZ / IN / TN / FL / OH / IL / NJ / VA）用 AWS Outposts 把運算放進州內、但邏輯上仍是 一個 CockroachDB cluster — region placement 配置決定哪些 range 釘在哪個 Outpost / AWS region。case 觀察段直接揭露「跨所有 region 一個 logical database」這個拓樸 fact。

讀者常問：

• 合規逼我每州一 cluster、但跨州帳戶 / 風控 / 欺詐偵測撞牆怎麼辦？
• REGIONAL BY ROW 跟 REGIONAL BY TABLE 怎麼選、GLOBAL 又在什麼場景？
• GLOBAL table 為什麼讀快但寫慢、預設為什麼不全部用？
• AWS Outposts 是 latency 工具還是合規工具？

對照 9.C40 Netflix：60+ multi-region cluster、最大 Gaming cluster 48-node 跨 4 region、locality 配置直接影響 cluster 規模治理。

對照 9.C14 Standard Chartered Aurora 7 cluster fleet：銀行業跨國合規邊界、走的是「每市場獨立 Aurora cluster」路徑 — 跟 Hard Rock 邏輯一個 cluster 的拓樸完全不同。兩條路徑沒有對錯、trigger 條件不同（合規顆粒 × 跨 boundary 業務邏輯需求）。

核心機制：三種 table locality + row-level region 標記

三種 locality 模式

CockroachDB 用 Range Sharding 把 multi-region table 抽象成三種 locality、配合 Data Residency 合規邊界決定 row 落在哪個 region：

REGIONAL BY ROW：每 row 帶 crdb_region 隱含欄位

REGIONAL BY ROW 是 Hard Rock 場景的主要選擇。每 row 自動帶一個 crdb_region 隱含欄位、根據這個欄位把 row 對應的 range 釘在指定 region：

1ALTER DATABASE sportsbook PRIMARY REGION "us-east1-az";
2ALTER DATABASE sportsbook ADD REGION "us-east1-nj";
3ALTER DATABASE sportsbook ADD REGION "us-east1-fl";
4
5ALTER TABLE bets SET LOCALITY REGIONAL BY ROW;
6
7-- 寫入時指定 row 屬哪個 region
8INSERT INTO bets (id, user_id, amount, crdb_region)
9VALUES (..., ..., ..., 'us-east1-nj');

CockroachDB planner 自動感知 crdb_region、把 read / write 路由到 row 所在 region 的 leaseholder。application 不用手動配 shard key、不用 application 端路由邏輯 — 這是 distributed SQL 的「宣告式 locality」優勢。

GLOBAL：每 region local read、跨 region sync write

GLOBAL table 適合 reference data — 變更少、read 頻繁、需要全球 local read latency：

• read：每 region 都有 leaseholder、本地 read p99 跟 single-region 一樣
• write：跨 region quorum、p99 100ms+

實務上 GLOBAL 只放國家代碼、貨幣表、規則 lookup 等 變更頻率低 的 reference data。把 high-write workload 設成 GLOBAL 是典型錯配（見失敗模式段）。

Follower read：non-voting replica 提供本地 read

CockroachDB 區分 voting 跟 non-voting replica：

• voting replica 參與 Raft majority、決定 commit
• non-voting replica 不參與 commit、只 serve Follower Read

REGIONAL BY ROW + SURVIVE REGION FAILURE 配合時：row 所在 region 是 voting + Leaseholder、其他 region 有 voting replica（survival 需要）+ non-voting replica（本地 follower read）。

Follower read 讀到的是 closed timestamp 之前的資料 — strong consistency 場景不能用（read-after-write 會 stale）、但 dashboard / reporting / 風控分析等 容忍 stale 場景大幅降低 cross-region latency。

配置語法跟驗證

 1-- 設 database 的 region
 2ALTER DATABASE mydb PRIMARY REGION "us-east1";
 3ALTER DATABASE mydb ADD REGION "europe-west1";
 4
 5-- 設 table locality
 6ALTER TABLE users SET LOCALITY REGIONAL BY ROW;
 7ALTER TABLE country_codes SET LOCALITY GLOBAL;
 8ALTER TABLE orders_us SET LOCALITY REGIONAL BY TABLE IN "us-east1";
 9
10-- 驗證
11SHOW LOCALITY FROM TABLE users;
12SHOW RANGES FROM TABLE users;  -- 看 replica 分佈
13EXPLAIN ANALYZE SELECT * FROM users WHERE id = 1;  -- 看 query plan 是否 local

對應 stale read 卡、table partitioning 卡 的具體機制實現。

操作流程：從合規 boundary 到 schema 配置

配置 multi-region database

第一步是把所有 region 加入 database：

1-- 假設 cluster 已跨 8 個州（透過 AWS Outposts 在每州內）
2ALTER DATABASE sportsbook PRIMARY REGION "us-east1-virginia";
3ALTER DATABASE sportsbook ADD REGION "us-east1-nj";
4ALTER DATABASE sportsbook ADD REGION "us-east1-fl";
5ALTER DATABASE sportsbook ADD REGION "us-east1-az";
6-- ...其他州

每個「region」對應一個 Outpost / AWS region 的 locality tag、CockroachDB Raft 根據 locality 自動分佈 replica。

Table-level locality 配置

bet placement / settlement table 走 REGIONAL BY ROW（資料跟玩家所在州綁定）：

1ALTER TABLE bets SET LOCALITY REGIONAL BY ROW;
2ALTER TABLE settlements SET LOCALITY REGIONAL BY ROW;

account / user profile 跨州統一帳戶 — 玩家可能在多州下注、但 主檔 留 single region：

1ALTER TABLE accounts SET LOCALITY REGIONAL BY TABLE IN "us-east1-virginia";

reference data（運動類別、賽事 metadata）— 全球變更少、每州都要快速 read：

1ALTER TABLE sports_metadata SET LOCALITY GLOBAL;

Application 端寫入

1-- 顯式指定 row 所在 region（推薦、明確）
2INSERT INTO bets (id, user_id, state, amount, crdb_region)
3VALUES (..., ..., 'NJ', 100.00, 'us-east1-nj');
4
5-- 或用 gateway_region() default（依 application 連到的 region）
6INSERT INTO bets (id, user_id, state, amount)
7VALUES (..., ..., 'NJ', 100.00);  -- crdb_region 自動填 gateway 端

gateway_region() 是便利但有風險的 default — 如果 application server 在 us-east1-fl 但 user 在 NJ 下注、row 會被放到 FL 而不是 NJ、違反 Wire Act 合規。Hard Rock 場景下顯式指定 crdb_region 是更安全的做法。

Rollback 邊界

locality 變更即時生效、Raft 自動 rebalance — 無不可逆動作。但 rebalance 期間 cross-region traffic 暴增、p99 短期 spike。production 環境改 locality 應該選低流量時段、並監控 rebalance queue。

失敗模式

「拆獨立 cluster 解合規但破壞業務邏輯」反模式（Hard Rock 對比 Standard Chartered、F4.10）

直覺路徑是「合規要求資料留某地理邊界 → 每邊界開一個獨立 cluster」、合規上沒問題。但獨立 cluster 之間：

• 玩家統一帳戶撞牆 — 每 cluster 各自有 user table、跨 cluster query 麻煩
• 跨州 reporting 要 N 個 cluster + ETL pipeline
• 欺詐偵測要 cross-state aggregated view — 獨立 cluster 拼不出

Hard Rock 選擇 邏輯一個 cluster + 物理跨州 Outpost placement — 合規 boundary 用 region placement 表達、不是 cluster fragmentation。對比 Standard Chartered：

• Standard Chartered Aurora 7 cluster fleet：銀行業跨國合規邊界、跨 cluster 業務邏輯需求弱（每市場用戶獨立、跨境統一帳戶不是核心 driver）→ 用 fleet 拓樸吸收合規可行
• Hard Rock Wire Act 跨州：跨州統一帳戶 + 跨州 reporting + 欺詐偵測是 核心業務需求 → 必須邏輯一個 cluster、用 locality + placement 吸收合規

兩條路徑沒有對錯、trigger 條件不同。判讀軸線：

• 合規顆粒（跨國 vs 跨州 vs 跨 AZ）
• 跨 boundary 業務邏輯需求強度（強 → CockroachDB locality / 弱 → 拆獨立 cluster 可行）
• 團隊運維能力（CockroachDB 邏輯一個 cluster vs Aurora 多 cluster fleet 的人月成本）

「Outposts 是 latency 工具」動機誤判（F4.13、case 反直覺判讀）

AWS Outposts 主要為「資料留某地理邊界」存在、latency 改善是 副作用。Hard Rock 策略段 2 明確警告：「決策時先看合規驅動力、latency 改善列為 bonus」。

若把 Outposts 當跨州 latency 改善工具、會在沒合規驅動的場景過度投資 — Outposts 硬體成本 + 維運複雜度遠高於純 AWS region 部署。實務判讀：

• 有合規驅動（Wire Act / GDPR / 各州博彩牌照）→ Outposts 是合理投資
• 純 latency 優化 → 用 AWS Local Zones、用 CDN、用 edge cache、不要碰 Outposts
• 兩者並存 → Outposts 投資按 合規 計算、latency 改善是 ROI 加分項

GLOBAL table write 太慢

GLOBAL table 每次 write 跨 region quorum、p99 100ms+。用在 high-write workload 是典型錯配 — 該用在 reference data（國家代碼、貨幣表、規則 lookup）。

判讀：

• write QPS < 10 + read QPS 跨 region 高 → GLOBAL 合理
• write QPS > 100 → 不要用 GLOBAL、改 REGIONAL BY ROW + 接受 cross-region read 偶爾走 follower

REGIONAL BY ROW 但 row 沒設 crdb_region

application 寫入時忘了設 crdb_region、default 走 gateway_region() — application server 所在 region 變成 row 的 region。常見後果：

• application server 集中部署 → 所有 row 跑同一 region、locality 失效
• application server 跟 user 不同 region → 合規 violation（Wire Act 場景）

修法：顯式指定 crdb_region、把 user 的合規區域當業務欄位明確管理。

Cross-region join 跑爆 latency

兩個 REGIONAL BY ROW table join、planner 要跨 region 拉資料、p99 暴漲。

修法：

• 兩個 table partition by 同樣 的 key（如：user_id）、保證 join 對應 row 在同 region
• 不能保證 co-location 時、考慮用 follower read 接受 stale 資料
• query 重寫成多步：先在各 region 算 local 結果、application 端 merge

Follower read 假設 strong consistency

non-voting replica 是 closed timestamp 之前的資料、read-after-write 場景仍會 stale。

修法：

• read-after-write critical（如：剛下注立刻顯示「下注成功」）→ 不能走 follower、要走 leaseholder
• dashboard / 分析 / reporting 容忍 stale → follower read 安全、大幅降 latency

Data residency 違規

受監管州 / 國資料應留 boundary 內、但 application 從別 region 寫入 row、沒設 crdb_region、資料跑出 boundary、合規 violation（Wire Act / GDPR / 各州博彩牌照都有類似條款）。

修法（schema-level + application-level 雙保險）：

• schema：REGIONAL BY ROW + crdb_region 是 NOT NULL + CHECK constraint 限制可選值
• application：寫入前明確驗證 crdb_region 對應 user 所在合規區
• 監控：定期跑 SELECT crdb_region, count(*) FROM bets GROUP BY crdb_region 確認分佈符合預期

Hard Rock 場景的組合配置（9.C41）

bet placement / settlement / account management 都需要跨州資料存取 + 州內合規 placement。Hard Rock 案例揭露的具體組合：

• REGIONAL BY ROW + crdb_region 標州別 + region placement pin Outpost
• account 跨州統一 → REGIONAL BY TABLE IN primary region、其他州走 follower read
• sports metadata → GLOBAL、reference data 全州 local read

這是滿足 Wire Act + 跨州業務邏輯的組合、不是唯一解、但揭露了 schema 設計的 判讀軸 — 不是「locality 越強越好」、是「locality 對應業務 + 合規邊界」。

容量與觀測

必看 metric

• Range locality distribution：range 分佈跟 locality 配置是否一致
• Cross-region query count：cross-region query 數量、locality 失效訊號
• Follower read rate：follower read 命中率、降 latency 效果
• Leaseholder distribution by region：leaseholder 在 region 間是否均勻

容量公式

• cross-region traffic = GLOBAL table write QPS × region count
• REGIONAL BY ROW 跨 region read = follower read rate × QPS
• storage 用量 = base storage × replication factor × (voting + non-voting replica count)

容量上限

• region count：建議 ≤ 5（多 region 增加 quorum latency + 維運複雜度）
• GLOBAL table 數量：建議只放 reference data、總 row 數 < 10 萬
• single range 寫 throughput ~1000 QPS（通用估算、見 HLC + Raft consensus）

回路徑

• 9.5 瓶頸定位流程 判斷 cross-region-bound vs CPU-bound
• 1.11 全球分散式 OLTP 上游合規 / latency 取捨

邊界與整合

Sibling deep articles

• survival goals：locality + survival goal 一起決定 replica placement
• transaction retry pattern：partition 降低 hot row contention 的 schema 路徑
• HLC + Raft consensus：leaseholder 跟 locality 的關係

跟 Aurora Global Database 對照

Aurora 不支援 row-level locality — 跨 region 只能 cluster-per-region + async replication。CockroachDB 在一個 cluster 內可以 fine-grained locality、application 不需要管 cross-cluster 路由。Aurora Global Database 適合 async DR 場景、不適合 跨 region 強一致 + row-level locality 需求。

跟 Spanner interleaved tables 對照

Spanner 的 Interleaved Table 跟 CockroachDB 的 REGIONAL BY ROW 概念類似（parent-child row co-location）、語法不同。Spanner 在 GCP region 內 placement、無 Outposts 等效 — Hard Rock 場景下 Spanner 不能直接套用。

Aurora DSQL / Spanner 對比

完整三家 distributed SQL 在 locality / multi-region placement 的取捨、見 aurora-dsql-spanner-decision-tree。

1.x 章節互引

• 1.11 全球分散式 OLTP 上游
• stale read 卡
• table partitioning 卡

何時不用本文

• single-region 部署、無 data residency 需求 → 用 default locality 即可
• 合規邊界 禁止 跨境 replica（如 Standard Chartered 模式）→ 拆 cluster-per-市場、不走本文 locality 路徑
• 純 latency 優化、無合規驅動 → 用 CDN / cache / Local Zones、不必動 schema

相關連結

• CockroachDB vendor overview
• 9.C41 Hard Rock Digital（concrete framing — 跨 8 州 + Outposts + 邏輯一個 cluster）
• 9.C40 Netflix（多 region locality 規模治理）
• 9.C14 Standard Chartered（fleet 拓樸對照、不同合規邊界）
• stale read 卡 / table partitioning 卡
• 官方：CockroachDB Multi-Region Capabilities / Table Localities / Follower Reads

本文是 CockroachDB vendor overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。本文聚焦 三種 table locality 怎麼選、選錯的 latency / 一致性後果與重配代價。Schema 怎麼配合 locality 設計（合規 boundary、跨州業務邏輯、Outposts 拓樸）主寫於 locality-aware schema、survival goal 的存活機制主寫於 survival goals、本文兩者都 cross-link、不重複展開。

問題情境：multi-region cluster 起來了、每張 table 該設哪種 locality

團隊把 CockroachDB 跨 region 拉起來、ALTER DATABASE ... ADD REGION 也跑完了，接下來面對的是逐張 table 的 locality 決策。這個決策的成本結構很不對稱：設對了，read / write 走本地 leaseholder、latency 貼著單區水準；設錯了，每次寫入或讀取都吃一趟跨 region round trip，p99 從個位數毫秒跳到上百毫秒。

multi-region table locality 是 把「資料的地理歸屬」跟「讀寫路徑」綁在一起 的宣告。CockroachDB 提供三種 locality，對應三種「資料屬於誰、誰要快」的業務形狀：

• REGIONAL BY TABLE：整張 table 歸屬單一 region，該 region 讀寫快、其他 region 慢。
• REGIONAL BY ROW：每一 row 各自歸屬一個 region，row 所在 region 讀寫快。
• GLOBAL：資料屬於所有 region，每個 region 本地讀都快，但寫入要跨 region 達成共識。

讀者進來最常卡的三題：

• 三種 locality 對應什麼業務形狀、判讀軸是什麼？
• GLOBAL 既然每區讀都快，為什麼不全部設 GLOBAL？
• 上線後發現 locality 設錯，重配的代價有多高、能不能無痛改？

這三題都是 把業務的資料歸屬與讀寫熱點，翻譯成副本拓樸 的設計決策，語法層面反而簡單。

問題情境最常見的 trigger：9.C40 Netflix 的 60+ multi-region cluster、最大 Gaming cluster 48-node 跨 4 region。case 揭露一個反直覺判讀 — multi-region 的主要動機是 region failure 0 downtime、不是降 latency；跨 region quorum 物理上會 增 寫入 latency。這條判讀直接決定 table locality 怎麼設：當 multi-region 的目的是 survival 而非 latency，把高寫入 table 設成 GLOBAL（跨區同步寫）就是把成本花在錯的地方。

9.C41 Hard Rock Digital 則提供 row-level 歸屬的 concrete framing：跨 8 州 sportsbook、bet 資料按下注州歸屬、邏輯上仍是一個 cluster。case 觀察段揭露「跨所有 region 一個 logical database」這個拓樸 fact — 也就是 row-level locality 撐起了「合規分州 placement + 單一邏輯 DB」的組合。Hard Rock 的合規驅動與 schema 設計細節在 locality-aware schema 展開，本文只取「row-level 歸屬」這個 locality 選擇本身。

核心機制：三種 locality 的判讀軸 + survival goal 互動

三種 table locality 的差異，本質是 leaseholder（讀寫入口）跟資料歸屬 region 之間的關係。leaseholder 機制屬前置、見 HLC + Raft consensus；本文聚焦三種 locality 把 leaseholder 放在哪、因此誰快誰慢。

判讀軸：資料歸屬的顆粒 × 讀寫熱點分佈

選 locality 的第一個判讀軸是 資料歸屬的顆粒：整張 table 屬於一個 region（table 級），還是每 row 各屬一個 region（row 級），還是屬於所有 region（global）。第二個判讀軸是 讀寫熱點落在哪：本地讀為主、本地寫為主、還是全球讀為主。

每一格的判讀都要回到該情境，不能只看表。

REGIONAL BY TABLE 適合 整張表的讀寫熱點集中在單一 region 的情況。例如一張只服務日本市場的訂單表，把整張表的 leaseholder 釘在 asia-northeast1，日本端的應用讀寫都走本地 leaseholder，跨區應用偶爾讀則走 follower read 接受 stale。判讀訊號：這張表的寫入請求是否 95% 以上來自同一 region。如果不是，table 級歸屬會讓多數寫入吃跨區延遲。

REGIONAL BY ROW 適合 每一 row 跟某個地理位置強綁定、但整張表跨多 region 的情況。玩家帳戶、訂單、下注紀錄都屬於這類 — 每筆資料屬於某個用戶所在 region，但整張表服務所有 region 的用戶。row 透過隱含的 crdb_region 欄位決定歸屬，leaseholder 跟著 row 走。判讀訊號：同一張表的不同 row，讀寫熱點是否分散在不同 region。是的話，row 級歸屬讓每個 row 都貼著自己的用戶。

GLOBAL 適合 讀遠多於寫、且每個 region 都要本地快讀 的 reference data。國家代碼、貨幣表、運動賽事 metadata 這類資料變更稀少、但每個 region 的每次查詢都要用到。GLOBAL 讓每個 region 都能本地讀（讀到 closed timestamp 前的一致快照），代價是寫入要跨 region 達成共識。判讀訊號：寫入頻率是否低到「跨區寫的慢可以忽略」。

為什麼不全部設 GLOBAL

GLOBAL 的「每區讀都快」看似適合全表套用，但它對 寫入 收取跨 region quorum 的全額成本。GLOBAL table 的讀之所以能本地完成，是因為 CockroachDB 維護一個全球同步的 closed timestamp，讓每個 region 都能安全地本地讀稍早的快照；維護這個 timestamp 的代價是每次寫入都要跟所有 region 協調。

Scope warning：GLOBAL table 的跨 region 寫入 p99、REGIONAL BY ROW 的本地寫入 p99、closed timestamp 的傳播間隔等具體數字，屬 vendor 規格與部署拓樸（region 距離、replica 數）的函數，三個 anchor case（DoorDash / Netflix / Hard Rock）都未揭露單一 table 的 latency 數字。本文只給量級判讀（本地 quorum vs 跨洲 quorum 差一到兩個數量級），具體值需 benchmark 自身拓樸並 cross-verify CockroachDB Table Localities 文件。

因此「全部設 GLOBAL」會把所有寫入推上跨 region 路徑，等於放棄了 distributed SQL 把寫入分散到各 region 的核心優勢。GLOBAL 的正確用法是限定在 變更頻率低、全球都要快讀 的 reference data。

Survival goal 怎麼跟 locality 一起決定副本拓樸

table locality 決定 leaseholder 放哪、讀寫走哪條路徑；survival goal 決定 副本要分佈到幾個 failure domain 才能在故障後存活。兩者一起決定每張 table 的副本拓樸。

survival goal 的存活機制本身（SURVIVE ZONE FAILURE vs SURVIVE REGION FAILURE、怎麼從業務 SLO 倒推、RTO / RPO 怎麼算）是 survival goals 的 SSoT，本文不重複展開。本文只取兩者 互動 的一個關鍵後果：把 SURVIVE REGION FAILURE 套到 REGIONAL BY ROW table 時，每個 region 的 row 不只需要本地 voting replica，還需要在 其他 region 放足夠的 voting replica 才能在整個 region 失效後仍達成 quorum。這會把跨 region 的 voting replica 數量推高，間接增加寫入要協調的範圍。

判讀路線：先依業務的資料歸屬與讀寫熱點選 locality（本文），再依業務的 region failure 容忍度選 survival goal（survival goals），兩者疊加後才得到最終副本拓樸與 latency 結構。

操作流程：配置、驗證、每步檢查生效

第一步：確認 database 已加入所有 region

table locality 的前提是 database 已宣告 region。先確認 region 列表正確，再設 table locality。

1-- 看 database 已有哪些 region、哪個是 primary
2SHOW REGIONS FROM DATABASE mydb;

驗證點：輸出的 region 數量與名稱要對齊實際部署的 region。少一個 region，後面把 table 設成該 region 的 REGIONAL BY TABLE 會直接報錯。

第二步：依判讀軸設定每張 table 的 locality

1-- 整張表服務單一市場
2ALTER TABLE orders_jp SET LOCALITY REGIONAL BY TABLE IN "asia-northeast1";
3
4-- 資料跟用戶地理綁定
5ALTER TABLE accounts SET LOCALITY REGIONAL BY ROW;
6
7-- 低寫入、全球本地讀的 reference data
8ALTER TABLE currency_codes SET LOCALITY GLOBAL;

驗證點：

1-- 確認每張 table 的 locality 設定符合預期
2SHOW CREATE TABLE accounts;   -- locality 子句會出現在輸出尾段

第三步：驗證讀寫路徑真的走本地

設了 locality 不代表查詢真的走本地路徑 — 寫入時 row 的 crdb_region 沒設對、或 query 沒帶上對應條件，仍會跨區。用 EXPLAIN ANALYZE 看實際 plan。

1-- 看 query 是否在 row 歸屬 region 本地完成、有沒有跨 region 拉資料
2EXPLAIN ANALYZE SELECT * FROM accounts WHERE id = $1;

驗證點：plan 中不應出現大量跨 region 的 distributed scan；REGIONAL BY ROW 的點查應落在 row 歸屬 region 的單一 leaseholder。

第四步：驗證副本分佈符合 locality + survival goal

1-- 看每張 table 的 range 副本實際分佈在哪些 region
2SHOW RANGES FROM TABLE accounts;

驗證點：副本分佈要同時滿足 locality（leaseholder 在歸屬 region）跟 survival goal（跨足夠 failure domain）。兩者衝突時，CockroachDB 以 survival goal 為硬約束調整副本數，這會反過來影響 latency — 對應 survival goals 的 latency 暴漲失敗模式。

失敗模式：locality 選錯的高代價回退

GLOBAL 套到高寫入 table

把高寫入 table（訂單、下注、status 變更）設成 GLOBAL，每筆寫入都跨 region 共識，寫入 p99 結構性暴漲、寫入吞吐被跨區協調卡死。徵兆：CockroachDB Console 的跨 region network traffic 隨寫入量線性成長、寫入 p99 跟 region 距離正相關。

修法：把 table 改成 REGIONAL BY ROW（按用戶歸屬）或 REGIONAL BY TABLE（按市場歸屬）。

Anti-recommendation：reference data 之外的任何 table，預設都不要設 GLOBAL。GLOBAL 的判準是「寫入頻率低到跨區寫的慢可以忽略」，高寫入 workload 直接排除。

REGIONAL BY ROW 但 row 沒帶正確 crdb_region

REGIONAL BY ROW 靠 crdb_region 決定 row 歸屬。寫入時沒顯式指定，default 走 gateway_region() — application server 所在 region 變成 row 歸屬。後果是 row 被釘在 application server 那一區，而非用戶所在區，locality 形同失效（甚至在合規場景違反 data residency，見 locality-aware schema）。

修法：寫入時顯式指定 crdb_region 為用戶所在 region，並用 NOT NULL + CHECK constraint 把可選值鎖死。

選錯 locality 的重配代價（高代價不可逆情境的回退敘事）

table locality 選錯，重配本身語法上一行就能改（ALTER TABLE ... SET LOCALITY ...），但 資料層面的重配代價高且有持續影響，需要專屬回退計畫，不能比照「改個 config 重啟」對待。

重配 locality 會觸發 CockroachDB 把受影響 range 的副本搬到新拓樸對應的位置。把一張大 table 從 GLOBAL 改成 REGIONAL BY ROW，或從 single region 改成 row-level 跨多 region，意味著大量 range 要 rebalance — 期間跨 region network 流量暴增、leaseholder 反覆換手、p99 持續波動，table 越大、region 越多，rebalance 窗口越長。這是隨資料量延長的背景過程，遠非秒級操作。

更關鍵的是 REGIONAL BY ROW 的 crdb_region 是 資料內容，不只是 metadata。如果原本 row 的歸屬區設錯（例如全部落到 application server 那一區），重配 locality 不會自動把 row 搬到正確的用戶 region — 還要 回填 crdb_region 欄位，這是一次 data migration，不是 schema 變更。合規場景下，錯誤歸屬期間寫入的資料可能已經違反 data residency，回退時要連同合規證據一起盤點。

回退計畫的要素：

• 重配前估算受影響 range 數量與資料量，換算 rebalance 窗口，選低流量時段執行。
• 重配 REGIONAL BY ROW 時，分開處理「locality 宣告變更」與「crdb_region 回填」兩個動作，回填走分批 update 並監控 contention。
• 重配期間監控 rebalance queue 與跨 region traffic，設好「波動超過閾值就暫停 rebalance」的 tripwire。
• 合規場景下，先盤點錯誤歸屬期間的資料是否已違規，再決定回填策略與是否需要合規通報。

Anti-recommendation：不要在 production 高峰時段直接對大 table 改 locality 試效果。locality 是「上線前依業務形狀想清楚再設」的決策，不是「線上 A/B 試」的旋鈕。

Cross-region join 跑爆 latency

兩張 REGIONAL BY ROW table join，若 join key 不保證兩邊 row 在同 region，planner 要跨 region 拉資料，p99 暴漲。

修法：兩張 table 用同一個歸屬 key（如 user_id），讓 join 對應的 row co-locate 在同 region；無法 co-locate 時，對容忍 stale 的查詢改走 follower read。

容量與觀測

必看 metric

• Cross-region query count：locality 是否生效的直接訊號，數值高代表查詢在跨區拉資料。
• Leaseholder distribution by region：leaseholder 是否落在資料歸屬 region，不均代表 locality 配置或 crdb_region 有偏。
• Rebalance queue size：locality 重配 / 副本搬遷期間的進度訊號，持續非零代表 rebalance 未收斂。
• Cross-region network bytes：GLOBAL table 寫入與 cross-region join 的成本訊號。

容量判讀

• GLOBAL table 的跨區寫入成本 ≈ 寫入 QPS × region 數，region 越多成本越高，所以 GLOBAL 只放低寫入 reference data。
• REGIONAL BY ROW 的跨區讀成本 ≈ 落到非歸屬 region 的讀 QPS，這部分若高，代表 crdb_region 歸屬與實際讀熱點不一致。
• region 數量建議維持精簡 — 每多一個 region，跨區協調與重配窗口都變長。

Scope warning：region 數量上限建議、單 range 寫入吞吐量級、closed timestamp 傳播間隔等為 vendor 通用估算，非 case 揭露數字，容量規劃前以 CockroachDB Multi-Region 文件 cross-verify 並 benchmark 自身拓樸。

回路徑

• 9.5 瓶頸定位流程 判斷 cross-region-bound vs CPU-bound。
• 9.6 容量規劃模型 region count × replica × latency budget。
• latency budget 卡 跨 region quorum 預算。

邊界與整合

Sibling deep articles

• locality-aware schema：schema 怎麼配合 locality 設計 — 合規 boundary、跨州業務邏輯、Outposts 拓樸、crdb_region 作為合規欄位的管理。本文是「三種 locality 怎麼選」、該文是「選好後 schema 怎麼配合」，兩者互補不重複。
• survival goals：survival goal 的存活機制與 SLO 倒推 — 本文只取「survival goal 與 locality 互動如何影響副本拓樸」這一個交點，存活機制本身以該文為 SSoT。
• HLC + Raft consensus：leaseholder 與 range 機制 — locality 決定 leaseholder 放哪，前置機制在該文。

跟 Spanner / Aurora 對照

Spanner 在 GCP region 內做 placement，無 AWS Outposts 等效；Aurora 不支援 row-level locality，跨 region 只能 cluster-per-region + async replication。完整三家 distributed SQL 在 multi-region placement 的選型對比，是 aurora-dsql-spanner-decision-tree 的 SSoT，本文不重展三方對比。

1.x 章節互引

• 1.11 全球分散式 OLTP 上游 latency / 一致性取捨。
• stale read 卡、follower read 卡 — GLOBAL 與跨區讀的一致性語意。

何時不用本文

• single-region 部署：用 default locality 即可，三種 locality 在單區無差異。
• 從 PostgreSQL 遷到 CockroachDB 的整體流程：見 PostgreSQL → CockroachDB migration，本文只處理遷移後的 table locality 配置。

相關連結

• CockroachDB vendor overview
• 9.C40 Netflix（multi-region 動機是 survival 非 latency）
• 9.C41 Hard Rock Digital（row-level 歸屬 + 單一邏輯 cluster）
• distributed SQL 卡
• 官方：CockroachDB Table Localities / Multi-Region Overview / Follower Reads