本文是 DynamoDB overview 的 implementation-layer deep article。同時是 #128 self-aware limitation 第 1 點「6 維仍可能漏類（identity / consistency / residency 三軸候選）」的 consistency 軸驗證。

Same protocol, different contract：consistency model 對照

DynamoDB 的 read 操作支援兩種 consistency：

兩者 同 protocol, same API, same table — 唯一差異是 application contract：能否接受 0-100ms 的 staleness。

跑 6 維 diff dimension audit 對「strongly consistent → eventually consistent」遷移：

6 維 audit 抓不到「Consistency contract = High」這軸。用既有 6 維歸類、會走 Type B drop-in + application change 中維獨立段；但這個歸類 漏掉真正的工作量：

• Application code change（加 ConsistentRead flag）：~10%
• Operational verification：~5%
• Application contract review（每個 read site 評估 staleness 是否可接受）：~85%

工作量主軸在 contract semantic 重審、不在既有 6 維任一個。Consistency 是 候選的第 7 維（或 8 維、跟 identity 並列）。

Consistency axis 是否獨立：3 個論據

Yes、consistency 是獨立軸：

1. Schema / paradigm / operational 不變 → consistency 仍可變：同 DynamoDB table、同 application、同 IAM、只改 ConsistentRead flag、cost 砍半但 application contract 改；其他 6 維皆 Low、但工作量 80%+ 在 contract review
2. Paradigm 是 high-level、consistency 是 low-level：Kafka ↔ NATS 是 paradigm 差（log-based vs subject-based）；DynamoDB strong → eventual 是 同 paradigm 內的 consistency 子議題；歸 paradigm 維度太粗
3. 可獨立發生：PostgreSQL READ COMMITTED → SERIALIZABLE migration 同 vendor 同 schema 同 operational、只改 isolation level；Cassandra LOCAL_QUORUM → EACH_QUORUM 同 vendor、只改 consistency level — 都是 consistency 獨立變動的 case

No、consistency 可塞 paradigm：

• 反論：consistency 是 paradigm 的子議題
• 拒絕：paradigm 涵蓋 核心抽象（OLTP / log / pub-sub / document）、consistency 是 正確性 contract 屬不同 axis

實證：本文 migration 工作量 85% 在 contract review、確認 consistency 是 獨立工作量主軸。

結構：類 Type B + consistency contract review 獨立段

跟既有 Type B Redis → DragonflyDB 對照、本文多出 consistency contract review 獨立段：

11. Same protocol, different contract（consistency axis 對照表開頭）
22. Consistency axis 是否獨立的論據
33. 結構 differentiator（類 Type B + contract review）
44. Read site audit (per-call site review)
55. Migration 流程（dual-read 觀察 + canary cutover）
66. Production 故障演練
77. Capacity / cost
88. 整合 / 下一步

8 章節、200-260 行。比標準 Type B 多 1 段（contract review）+ 1 段（axis 獨立論據）。

Read site audit：per-call site contract review

不是 table-level 決定 consistency、是 call site-level 決定。每個 GetItem / Query / Scan 必須單獨 audit：

 1# Pre-audit application code
 2# Find all DynamoDB read sites
 3$ grep -r "table.get_item\|table.query\|table.scan" src/
 4
 5# Per-site contract review template:
 6# - Site: src/order_service.py:123 - get_item by order_id
 7# - Context: 顯示 order detail page、user 剛點「我的訂單」
 8# - Contract: user 可接受 100ms 內 stale data?
 9# - Decision: YES → ConsistentRead=False, saves 50% RCU
10#             NO  → keep ConsistentRead=True

Audit 分類矩陣（典型 application）：

audit 完後 application 端 60-80% read site 可改 eventual、剩餘 20-40% 保留 strong；整體 RCU cost 降 30-40%。

Migration 流程

Phase 0：Audit + classify

• Grep application code 找所有 read site
• per-site contract review、決定 strong / eventual
• 估計 RCU saving

Phase 1：低風險 site 切換

 1# Before
 2response = table.get_item(
 3    Key={'order_id': order_id},
 4    ConsistentRead=True  # 預設保守
 5)
 6
 7# After（顯式設）
 8response = table.get_item(
 9    Key={'order_id': order_id},
10    ConsistentRead=False  # 明示 eventual OK
11)

從 background job / search result 開始（低風險、staleness impact 低）、跑 1 週觀察 application metric。

Phase 2：中風險 site 切換

• User-facing list query
• Dashboard refresh
• 配 application-side 「last updated X seconds ago」hint 讓 user 知道是 cached/stale

Phase 3：審慎 site 保留 strong

• Read-your-write pattern
• Transactional read
• Financial / payment-critical lookup

Decision document 寫進 ADR、之後新 read site 直接套規則。

Production 故障演練

Case 1：Read-your-write 失效、user 看到自己沒提交的舊資料

徵兆：user 在 settings page 改了 email、submit 後跳轉首頁、首頁 widget 顯示舊 email 5-30 秒；user feedback「我改了但沒生效」。

根因：首頁 widget 用 ConsistentRead=False 讀 user profile、剛 commit 的 write 還在 propagate；違反 read-your-write semantic。

修法：

1. Read-your-write 場景強制 strong read：user 自己 fetch 自己的 data、加 ConsistentRead=True
2. Application-side cache invalidation：write 後立刻 invalidate local cache、避免 stale read 餵 user
3. Routing：user-self-fetch 路由到 strong read、其他 user 看 user 用 eventual read（90% 流量仍便宜）

Case 2：跨 record consistency 假設失效

徵兆：application 寫 order + 寫 inventory（兩個 record）、之後 read order + read inventory；發現有時 order 已寫 inventory 沒寫、application 顯示「order created but inventory not updated」、business state inconsistent。

根因：DynamoDB 沒 transaction 跨多 record（除非用 TransactWriteItems API）；eventual read 加劇 inconsistency window；strong read 並不解決根因。

修法：

1. 架構：跨 record 寫入用 TransactWriteItems、確保 atomic
2. read 端 saga pattern：accept eventual + application-level retry/reconcile
3. eventual consistency 不是 root cause：strong read 也會看到 inconsistency、修跨 record write 是根因解

Case 3：Background job retry 跑舊資料

徵兆：background job 每 5 分鐘掃 unprocessed orders、用 ConsistentRead=False；偶爾 job retry 2 次都 process 同 order、duplicate processing。

根因：job round 1 抓到 unprocessed order → mark as processed；job round 2 read 仍看到 未 mark 的舊狀態（eventual stale）、又 process 一次。

修法：

1. Idempotent processing：用 order ID + 自己 dedup 表、不依賴 DynamoDB consistency
2. Conditional write：UpdateItem 加 ConditionExpression: attribute_not_exists(processed_at)、duplicate 由 DynamoDB 拒絕
3. 不切 strong：background job 切 strong 也只是 減少 duplicate 機率、不解決；用 idempotent + conditional 才對

Case 4：Cost 沒降反升、application 改錯方向

徵兆：切換 6 個月後 RCU 成本反而上升 20%；audit 後發現 application 加了大量 background scan 用 ConsistentRead=False、scan 本身就比 query 貴、cost 飆。

根因：team 把「consistency 砍半 = cost 砍半」過度推廣、加了原本不存在的 read site；新 read 即使 eventual 也是 新 cost。

修法：

1. Migration scope 內 freeze new read：consistency 切換期間禁止加新 read 邏輯
2. Cost monitoring 在切換前 baseline：對齊原 RCU usage、新 read 出現必須單獨 review
3. Scan vs Query：跑 sample data、確認 application 用 Query 不是 Scan（Scan 對所有 partition 讀 / Query 對 partition key 讀）

Case 5：故障期間 eventual read 還能 work、應變流程沒覆蓋

徵兆：us-east-1 partial outage、strong read 開始 timeout、application 切到 fallback；但 fallback 邏輯只 cover「全 region fail」、沒 cover「strong fail / eventual ok」中間狀態；流量打到 fallback 路徑、出乎預期慢。

根因：DynamoDB 提供 partial consistency degradation — leader replica 不可用時 strong read 失敗、secondary 仍 alive、eventual read 仍可；application 沒設計這個中間狀態的處理。

修法：

1. 明示 fallback strategy：strong read 失敗時 application 端 retry with eventual + warning user「showing potentially stale data due to system degradation」
2. Circuit breaker per-consistency-level：strong read circuit 跟 eventual read circuit 分開、避免一邊 fail 拖另一邊
3. DR drill 覆蓋此 case：故障演練不只「全失敗 vs 全 work」、要演 partial degradation

Capacity / cost

判讀：完全 strong 是 過度保守、完全 eventual 是 過度激進；mixed 是 sweet spot、但 audit 工作量大。

整合 / 下一步

跟 PostgreSQL READ COMMITTED → SERIALIZABLE 對照

PostgreSQL isolation level migration 也是 consistency axis 變動、但方向相反（弱 → 強）；同樣需要 per-call-site review、application 端可能撞 serialization failure 處理。

跟 Cassandra LOCAL_QUORUM → EACH_QUORUM 對照

Cassandra tunable consistency 是另一個 consistency 獨立軸 case；EACH_QUORUM 跨 DC 需所有 DC quorum、latency 增、availability 降。

跟 Aurora read replica 對照

Aurora read replica 也涉 eventual read decision；application 路由策略類似但 mechanism 不同（DNS-based vs API flag）。

下一步議題

• Consistency axis 升級為第 7 維 audit dimension：累積 PostgreSQL isolation level / Cassandra tunable consistency / Aurora reader endpoint 3-5 個 case 後評估
• Sub-dimension proposal：consistency axis 可拆 sub-dimension - read consistency / write consistency / replication lag tolerance / serialization level
• 跟 paradigm 軸的邊界釐清：CRDT / event sourcing 是 paradigm 還是 consistency model 選擇？

相關連結

• 上游 vendor 頁：DynamoDB
• 平行 deep article：Redis → DragonflyDB（Type B drop-in 對照）
• 平行 axis 候選驗證 (sibling)：Vault → AWS Secrets Manager（identity 候選） / PostgreSQL Multi-Region GDPR Rollout（residency 候選）
• Methodology：Migration playbook methodology / #128 self-aware limitation 第 1 點（consistency axis 候選驗證、本文是該驗證的 dogfood）

全球分散式 OLTP 解決一個傳統 DB 做不到的問題：跨地理位置 同時 維持強一致性、低延遲、高可用性。CAP 定理過往把這視為「三選二」，但近 15 年的工程進展（Google Spanner、AWS Aurora DSQL、CockroachDB、Microsoft Cosmos DB 等）顯示「在投入 專屬硬體 或 特殊演算法 的條件下、可以同時拿到 strong consistency + global distribution + 可接受 latency」。

本章整理這類系統的工程設計、容量取捨、跟傳統 single-region OLTP 的差異。讀完後讀者能回答：什麼業務需求需要 global OLTP、跨 region quorum 的延遲代價、選 Spanner vs Aurora DSQL vs Cosmos DB 的決策依據。

跟 1.3 Transaction Boundary 的關係：1.3 處理 single-region OLTP 的 transaction 設計、本章處理 multi-region OLTP 的特殊取捨。

跟 1.10 KV / Document DB 容量規劃 的關係：1.10 KV 通常 eventual consistency 全球分散容易、本章處理 強一致 全球分散的工程挑戰。

CAP 跟 PACELC：理論工具

選擇全球 DB 前要先理解兩個理論框架。

CAP 定理：分散式系統 發生分區（network partition） 時、必須在 Consistency 跟 Availability 二選一。

• CP 系統：強一致、partition 時拒絕服務（Spanner、Cosmos DB strong）
• AP 系統：高可用、partition 時可能回舊資料（Cassandra、DynamoDB Global Tables）

PACELC（Daniel Abadi 提出）：擴充 CAP、加上「沒 partition 時」的取捨。

• 沒 partition 時：Latency vs Consistency 二選一
• 結合表示：PA/EL（partition 時選 Availability、平時選 Latency）vs PC/EC（partition 時選 Consistency、平時選 Consistency）

工程含義：

• Spanner、Aurora DSQL、Cosmos DB strong：PC/EC — 永遠選一致、付出 latency
• Cassandra、DynamoDB Global Tables：PA/EL — 永遠選快、付出可能不一致
• Cosmos DB session：PA/EL 但對同一 session 內保持 EC — 妥協方案

選 global DB 不是「哪個最好」、是「業務需要哪一邊」。金融交易、ticketing inventory、payment ledger 通常需要 EC；社群 feed、推薦、analytics 通常 EL 夠用。

Spanner / TrueTime 模型

Google Cloud Spanner 是目前最成熟的 global strong-consistency OLTP。

TrueTime API：用 GPS + 原子鐘提供「全球 unambiguous 時間戳」、解決分散式系統最難的問題之一 — 跨節點時序排序。

External consistency（線性化）：用 TrueTime 保證「全球任何節點看到的交易順序、跟 wall clock 一致」。比 CAP 的 strong consistency 更強。

容量特性（引自 9.C10 Spanner 案例）：

• 內部峰值 > 10 億 requests / 秒
• 線性擴展：2 nodes → 45K reads/sec、4 nodes → 90K reads/sec
• 跨地區交易延遲 100-200ms（quorum round-trip 不可壓縮）
• multi-region instance 可設定 quorum location（影響哪幾個 region 必須同意）

線性擴展為什麼是 OLTP 設計的最高目標

「2 nodes → 45K reads/sec、4 nodes → 90K reads/sec」這個線性對應在傳統 OLTP（PostgreSQL、MySQL）做不到。原因是 跨節點交易需要 coordinator 確認順序、coordinator 本身是 bottleneck。加更多節點不會線性加吞吐、因為 coordinator 處理速度跟不上、其他節點得排隊等。

Spanner 用 Paxos + TrueTime 把 coordinator 變成「拓樸感知的多 leader」、每個 leader 只管自己 partition、不需要全域 coordinator。這層演算法 + 硬體（GPS + 原子鐘）配合、才達成線性擴展。

為什麼這個 frame 對選型重要：讀「Spanner 撐 10 億 req/sec」不該理解成「能力差距」、而是「設計差距」— 傳統 OLTP 不是「沒它快」、是「結構上做不到線性」。如果業務未來會跨 region 擴展、必須在最初就選 distributed SQL、不是先用 PostgreSQL 再「之後加 sharding」。

對等技術跟取捨：

• AWS Aurora DSQL：用其他協議（OCC + 分散式時鐘）達成跨 region strong consistency、不用 TrueTime 硬體。
• CockroachDB：用 HLC（Hybrid Logical Clock）+ Raft、可在通用硬體上跑、但 cross-region linearizability 需要 OCC retry。
• TiDB：用 TSO（Timestamp Oracle）服務發 global timestamp、TSO 本身是 single point、可用性要靠 TSO failover 設計。

TrueTime 是 專屬硬體投資、其他方案是 軟體 only、兩者一致性保證等級類似、但運維成本跟認證難度差很大。可複製性低的 TrueTime 是 Google 的競爭優勢、不是普遍 best practice。

容量規劃：

• 節點數量 = 容量單位（每年 review）
• 跨 region quorum 配置決定 latency baseline
• 不能像 single-region OLTP 那樣短期擴容、需要提前 ramp

適用場景：

• 金融交易、ticketing inventory
• 全球客戶但需要強一致
• 不能容忍跨地區 stale read 的業務

不適用：

• 跨洲低延遲（沒辦法、TrueTime 也壓不下 100ms 跨洲）
• 高 throughput 但容忍 eventual consistency（Bigtable / Cassandra 更便宜）

分散式 SQL 的 over-provision 屬結構性成本

分散式 SQL（TiDB、CockroachDB、Spanner）要求恆常 over-provision、是結構性成本、不是 capacity planning 失誤。三個原因都來自跨節點協調的物理需求：

• 跨節點 transaction 需要 coordinator 角色、leader election 在尖峰當下不能發生、否則整個 cluster 卡住。
• 預留 buffer 讓 leader / follower lag 在尖峰時仍能收斂、否則 replication lag 爆增、讀走 replica 的 query 拿到太舊資料。
• 跨 region quorum 在某個 region 暫時不可用時、剩下 region 要能繼續 quorum、所以每 region 的容量都要 >= quorum 所需。

對應 9.C20 Zomato — Zomato 從 TiDB 遷出是業務需求側的判斷：該 workload 本身就能接受 eventually consistent、為 strong consistency 付的 over-provision 屬於浪費。判讀重點：strong consistency 是業務需求時、distributed SQL 的常態 over-provision 是合理代價；業務需求不到這個層級時、KV / 傳統 OLTP 是更划算的選項。

選型公式：先問業務需求要什麼一致性層級、再選 DB 類型、避免倒過來「先選 DB 再硬塞需求」。

Aurora DSQL：AWS 的全球 strong consistency 答案

AWS 在 2024 re:Invent 推出 Aurora DSQL、是 AWS 對 Spanner 的回應。

設計特點（引自 Aurora DSQL announcement）：

• 跨 region active-active write
• 強一致性（線性化）
• PostgreSQL wire protocol compatible（應用層改動小）
• Serverless（不必管 instance）

跟 Spanner 的差異：

• Spanner 用 TrueTime 硬體、Aurora DSQL 用其他協議
• Aurora DSQL 跟 PostgreSQL 相容（容易遷移）、Spanner 是專屬 SQL dialect
• Aurora DSQL 較新（2024）、生態還在成長
• Spanner 服務時間長（內部 2007、外部 2017）、production 案例多

適用場景：

• AWS 生態用戶想要 global strong consistency
• 已用 Aurora / PostgreSQL、想擴展到 multi-region
• 應用層想保留 PostgreSQL ORM

CockroachDB 跟 TiDB：自管選項

如果不想 vendor lock-in、或需要 on-prem 部署、選擇是 self-managed distributed SQL。

CockroachDB：

• 開源、可自管或用 Cockroach Cloud
• 跟 PostgreSQL wire protocol compatible
• 線性擴展、跨 region 部署、強一致
• 設計理念近 Spanner、但不用 TrueTime（用 HLC + Raft）

TiDB：

• 開源（PingCAP）、可自管或用 TiDB Cloud
• 跟 MySQL wire protocol compatible
• TiKV + TiDB 分層架構
• 中國市場大量使用、亞洲生態成熟

選擇取捨：

• vendor lock-in 風險 → 選 CockroachDB / TiDB
• 想 managed → 選 Spanner / Aurora DSQL
• 已用 PostgreSQL → 選 CockroachDB / Aurora DSQL（migration 容易）
• 已用 MySQL → 選 TiDB

對應案例：9.C20 Zomato 從 TiDB 遷出（理由不是 TiDB 不好、是 NewSQL 必須 over-provision、KV NoSQL 對該 workload 更划算）。

Cosmos DB multi-region write 模式

Azure Cosmos DB 提供 五個一致性層級、是 multi-region OLTP 最有彈性的選擇之一。

五個 consistency level（從強到弱）：

1. Strong：linearizable、跨 region quorum
2. Bounded staleness：訂版本 / 時間上限
3. Session consistency：同 session 內強一致
4. Consistent prefix：保證寫入順序
5. Eventual：最便宜、最終一致

Multi-region write 特色：

• 每個 region 都能寫、不必所有寫入回主 region
• conflict resolution 用 LWW（Last-Writer-Wins）或自訂 stored procedure
• 跟 Spanner 的 strong consistency 不同 — 是 AP 系統、不保證 linearizability

適用場景：

• 全球用戶分布、想 寫入本地 region 減延遲
• 容忍 eventual consistency（電商商品評論、社群動態）
• 不能容忍跨 region failover 中斷

對應案例：

• 9.C11 Minecraft Earth — AR 玩家位置用 session consistency、跨 region 寫入
• 9.C21 ASOS — Black Friday 全球用戶、Cosmos DB 跨 region 複製
• 9.C30 Microsoft 365 — 分析 platform 用 weakest acceptable consistency、最大 throughput

跨地理合規：法規限制下的 global OLTP

部分產業（金融、醫療、政府）有 資料駐留 要求 — 特定國家的資料不能離境。這跟全球分散式 OLTP 的設計有 conflict。

典型法規：

• 歐盟 GDPR：歐洲用戶資料應留歐
• 中國《網路安全法》、《資料安全法》：中國用戶資料留中國
• 印度資料保護法：印度金融資料留印度
• 美國各州 healthcare（HIPAA）：醫療資料規範
• 金融業：各國央行通常規定本地交易資料留本地

設計策略：

• 多個獨立 cluster、每個合規區一個。不是 single global cluster。
• meta-data 可以 global（用戶 profile 摘要）、transaction 必須 local
• 跨區查詢通過 federated query 或 ETL、不是直接 join

對應案例：

• 9.C14 Standard Chartered — 7 個受監管市場、各自獨立 Aurora cluster、不能合併
• 9.C24 Genesys — 15 主 region + 5 衛星、按合規區分布
• 9.C32 Clearent — 美國支付業務、Azure SQL Hyperscale + 美國 region

延遲代價：跨 region quorum 不可壓縮

全球 strong consistency 必須付的延遲代價來自物理。光速跑跨大西洋（紐約 ↔ 倫敦 5500 km）大約 27ms one-way、實際網路延遲 70-90ms（含路由 / 處理）。任何 strong consistency 系統都不能比這個快。

典型跨 region quorum latency：

• 同 region 跨 AZ：1-3ms
• 同 continent 跨 region（us-east-1 ↔ us-west-2）：50-80ms
• 跨 continent（us ↔ eu）：80-120ms
• 跨地球（us ↔ asia）：150-250ms

工程含義：

• SLO 訂 p99 < 50ms 跨 continent strong consistency → 不可能達成
• 必須在 SLO 設計時就接受跨 region 的物理 floor
• 業務不需要 strong consistency 的話、用 session / eventual 換 latency

對應案例：

• 9.C3 Coinbase — sub-ms 需求、無法跨 region、用 single-AZ cluster placement
• 9.C12 Riot Games — 35ms VALORANT 延遲門檻、靠 region cluster 滿足、不靠 global DB

詳見 Latency Budget 卡片。

業務的不同延遲代價曲線

讀「100-200ms 跨洲延遲」這種數字、不能只看絕對值、要看 業務代價怎麼隨延遲變化。不同業務型態的延遲代價曲線不同、決定能不能用 strong consistency 全球分散。

B2B agent 操作介面（客服平台、CRM）：延遲代價的特性是 累積。agent 一通客戶電話內連續操作數十次、每次卡 1 秒、累積 30 秒讓 agent 在用戶面前沉默 — 客服效率直接掉一半、客戶等不及掛電話、agent 績效跟 NPS 同時下降。專屬訊號是「單次 latency 看似可接受、agent 體感卻變慢」。對應 9.C24 Genesys 用 15 個 region 把任一 agent 的 DB 延遲壓到 < 50ms — 客服 SaaS 對單次延遲的容忍區間遠窄於一般網路服務。

B2C 終端用戶（社群、電商）：延遲代價是 一次性跳離。用戶等 1 秒會抱怨、等 3 秒會跳離；但完成一個操作就走、不會像 B2B 累積多次。容忍區間在 200ms-500ms、超過就掉 conversion。專屬訊號是「session bounce rate 跟 latency p99 高度相關」、不是看平均。

金融交易（payment、trading）：延遲代價有兩面、是其他業務型態少見的結構。一面是用戶體驗（付款卡 = 結帳放棄）、另一面是 系統正確性（交易順序錯 = 對帳異常、稽核失敗）。後者讓金融業願意付 100-200ms 換 strong consistency、因為對帳成本遠高於延遲成本。專屬訊號是「願意接受比 B2C 更高的 latency budget、但拒絕任何 consistency 妥協」。對應 9.C14 Standard Chartered 7 個受監管市場的設計。

IoT / Telemetry：延遲幾乎無業務代價（資料晚 10 秒進來、報表還是準）、但 throughput 才是主導指標。原因是這類業務的價值來自 大量裝置的聚合趨勢、不是 單一裝置即時回應；只要事件最終到達且順序合理、晚一點不影響決策。專屬訊號是「百萬裝置同時上報、寫入吞吐才是 SLO、latency 不在 alert 條件裡」。選型上 KV 或時序 DB 比 strong-consistency OLTP 更划算。

判讀重點：選 global OLTP 前先畫業務的延遲代價曲線、再決定能付多少 latency budget 給 strong consistency。「100ms 跨洲太慢」這個直覺反射只在沒有對帳 / 累積 / 趨勢這些業務代價時成立。

容量規劃：跟 single-region OLTP 完全不同

全球分散式 OLTP 的容量規劃有獨特挑戰。

容量單位：

• Spanner：節點數
• Aurora DSQL：serverless 自動（按 ACU 計費）
• Cosmos DB：RU/s（每個 region 獨立配置）
• CockroachDB / TiDB：節點數 + storage

規劃要點：

• 每個 region 獨立規劃（跨 region 不能 amortize）
• quorum 配置決定哪些 region 必須同意（影響 failure domain）
• 跨 region replication lag 是 SLO 一部分
• 不能像 single-region 那樣 reactive 擴容、必須 predictive

對應 9.6 容量規劃模型：全球 OLTP 是「不可水平擴容服務」的延伸 — 不只「單機極限」、是「跨 region 協調的物理極限」。

可用性目標的成本曲線

「我們要 99.99% 還是 99.999%」這個問題不該用直覺答、要先看每多一個 9 帶來的成本是多少。可用性是非線性、不是線性。

九的數學意義：

為什麼 99.99 → 99.999 是指數成本而非線性：每多一個 9、要求 每一層基礎設施 都要對等冗餘。

• 99.9 → 99.99：加 multi-AZ active-active、~2-3x 成本
• 99.99 → 99.999：加 multi-region active-active、+ DR 演練、+ failover 自動化、+ 監控覆蓋率拉滿、~5-10x 成本
• 99.999 → 99.9999：加多 cloud、+ 異地災備、+ 全自動 failover、+ 全鏈路演練、~20-50x 成本

適用場景的業務理由：

• 99.99%（受監管產業、付款）：合約 SLA 通常落在這層。受監管金融在中央銀行 / 金融監管機關的書面要求下、年度書面合規會審查 downtime 紀錄、超過 52 分鐘 / 年要解釋；付款 gateway 對商家 SLA 通常承諾 99.99%、低於這個值會被合作夥伴扣保證金。
• 99.999%（客服 SaaS / telco）：5x9 是 B2B 客服 SaaS 跟電信業的 合約義務、不是行銷話術。對應 9.C24 Genesys — 客服平台用 15 主 region + 5 衛星 region 達 99.999%、架構成本約是 single-region 的 15 倍、但 B2B 客服合約要 5x9、這是合理投資。對應 9.C5 Amazon Ads — 廣告計費 1 分鐘斷線可能損失幾百萬美金廣告收入、5x9 對應真實營收邊界。電信業 911 緊急通話必須 5x9 是更嚴格的法規層級。
• 99.9999%（核電、航空管制）：6x9 不只是工程目標、是 公共安全法規。核電廠 SCADA 系統、空管雷達、軌道交通信號這類業務 30 秒 / 年的中斷會威脅生命、所以付得起跨多 cloud / 異地災備 / 全鏈路演練的成本。一般網路服務談 6x9 通常是過度設計。

SLO 木桶效應：99.999% 是 系統整體 數字、不是 DB 單獨。DNS、load balancer、application、DB、storage 任何一層 single-region 就破壞整體 SLO。傳統工程師常以為「DB 多 region 就好」、忽略 application 跑在 single-region 的話、application down = 整體 down。

要達成 5x9、要 每一層 都 multi-region active-active、且 failover 流程能自動執行（人類在事故當下做不到 5 分鐘內完成切換）。對應 05 部署平台模組 的跨 region 部署、跟 06 可靠性驗證模組 的 DR 演練。

Region 成本曲線：N 個 region 的成本約是 1 個 region 的 N 倍（DB + compute + storage 都要複製）、但業務收益不是線性。

• 1 region：覆蓋本國用戶
• 3 region（同 continent）：覆蓋整 continent、延遲 < 50ms
• 6 region（跨 continent）：覆蓋全球、延遲 100-200ms
• 15 region：每個用戶 < 50ms 接入（如 Genesys 模式）

從 6 region → 15 region 的成本是 2.5x、但用戶體驗改善（50ms 延遲）對 B2B 客服很關鍵、對 B2C 推薦系統幾乎無感。region 數量選擇要看 業務模型對延遲的敏感度、不是工程「越多越好」。

Sharding 粒度跟業務一致性需求

distributed SQL 跟 single-cluster SQL 之間還有一層：多個獨立 cluster + 應用層 sharding。選哪個跟業務的一致性需求有關。

Hyperscale / Aurora 同類設計（storage / compute 分離）：

• AWS Aurora、Azure SQL Hyperscale、GCP AlloyDB、Spanner 都採類似工程哲學 — log-structured 分散式 storage + 獨立 compute scale
• storage 最高通常 100 TB（Hyperscale）、超過要 sharding
• compute 上限是 instance type（80 vCore 等）、超過要 sharding 或換 distributed SQL

對應 9.C32 Clearent — 5 億筆/年支付交易、用 Hyperscale 撐單一 cluster、沒拆 sharding 是因為支付業需要 跨 merchant 對帳一致性、共用 OLTP 比拆 cluster 划算。

選 vendor 看生態、不看技術：Hyperscale 跟 Aurora 工程哲學一致、選哪家取決於 application 已在哪個 cloud。AWS 客戶選 Aurora、Azure 客戶選 Hyperscale、GCP 客戶選 AlloyDB / Spanner。技術差異小、生態差異大（IAM 整合、observability tooling、計費綁定）。

業務一致性需求決定 sharding 粒度：

• 微服務各自 OLTP（Netflix Aurora consolidation）：每個微服務有自己的 Aurora cluster、跨服務一致性靠 application 層 saga / outbox。適合服務間業務 天然解耦（用戶服務、訂單服務、商品服務各自 owned data）。Query path 上、跨服務查詢必須走 API 而非 SQL JOIN、要接受查多個服務多次往返；一致性 path 上、跨服務 transaction 用 saga + compensation、容忍中間態。
• 微服務共用 OLTP（Clearent Hyperscale）：所有微服務共用一個大 cluster、跨服務一致性靠 DB transaction。適合業務 天然耦合（payment 跟 refund 跟 chargeback 必須在同一 transaction）。Query path 上、可以用 SQL JOIN 直接查跨服務資料、簡單；一致性 path 上、所有微服務共享一個 schema 演進邊界、schema migration 影響所有服務、要協調。
• Sharding by tenant（B2B SaaS）：每個 enterprise tenant 自己 cluster、適合 tenant 之間完全隔離、大客戶可能要求專屬 cluster。Query path 上、跨 tenant 查詢（例如平台級報表）要走 federated query 或 ETL 聚合、不能直接 join；運維 path 上、每個 tenant cluster 的容量規劃、backup、upgrade 都獨立、運維工時隨 tenant 數量線性成長。
• Sharding by region（受監管產業）：每個合規市場自己 cluster、合規驅動、不是性能驅動。對應 9.C14 Standard Chartered 7 個市場各自獨立。

判讀重點：sharding 不是「擴容到不夠才做」、是「業務模型決定的初始設計」。等到 single cluster 撐不住才開始 shard、會踩進「跨 shard 一致性」的工程地雷區、修改成本遠高於初期設計成本。Managed DB（Aurora、Hyperscale）的容量上限是 已知 的、設計時就該知道未來何時觸發 sharding。對應 1.1 高併發資料存取 的 storage 層 replication 段 — Hyperscale / Aurora / Spanner 同類設計的容量上限同樣是 sharding 觸發點。

案例對照

下一步路由

• 上游：1.3 Transaction Boundary（single-region OLTP）
• 平行：1.10 KV / Document DB 容量規劃（KV 全球分散）
• 下游：1.12 大規模 DB 遷移實戰（含「預設 DB 治理 pattern」— 平台規模化階段的 OLTP 選型治理）
• 跨模組：9.6 容量規劃模型、9.12 SLO 與 Performance Budget、0.2 State Storage Selection、7.11 Data Residency
• Spanner 深入：TrueTime API 深入、一致性模型對照、interleaved table schema migration
• CockroachDB / Aurora DSQL 深入：Aurora DSQL / Spanner / CockroachDB 決策樹、CockroachDB transaction retry pattern、survival goals、locality-aware schema
• Aurora 多 region 深入：global database multi-region、跨 AZ failover RTO
• Cosmos DB 多 region 深入：一致性層次工程、多 region write 衝突

既建知識卡片

• Transaction Boundary
• Latency Budget
• Universal Scalability Law
• Saturation Point

本文是 Firestore overview 的 deep article。寫作參照 Vendor 深度技術文章寫作方法論。

問題情境：改一個使用者名稱要改一千筆

一個社群 app 的貼文列表要顯示作者頭像與名稱。關聯式思路是貼文存 authorId、查詢時 JOIN users 表。但 Firestore 沒有 JOIN——要嘛 client 每顯示一則貼文就多查一次 users（列表 20 則就 20 次額外讀取），要嘛在貼文 document 裡直接存一份 authorName 與 authorAvatar 副本。為了讀取效率，多數人選後者。

副本一上線就埋了一致性債：使用者改了名稱，他過去發的一千則貼文裡的 authorName 還是舊的。改名這個動作從「更新一筆 users document」變成「更新一千筆貼文 document」。這篇處理 Firestore 反正規化的建模決策、如何用 fan-out write 維護副本一致、以及這套手段撐不住時的退場。

核心概念：反正規化是查詢邊界逼出來的

關聯式資料庫預設正規化，靠 JOIN 在查詢時組合資料；Firestore 沒有 server 端 JOIN，組合資料只有兩條路：client 多次查詢自己組，或寫入時就把要一起讀的資料存在一起。後者就是反正規化——它不是 Firestore 的「壞習慣」，是 client 直連 + 無 JOIN 的查詢模型逼出來的必然建模。

反正規化的判斷單位是 access pattern，不是資料的「正規與否」。問題不是「該不該複製」，而是「這份資料在哪些讀取路徑上要被一起讀到，複製它的一致性維護成本，比每次多查一次划不划算」。判斷有三個輸入：

讀寫比。讀多寫少的資料適合反正規化——複製成本攤在少數寫入上、省下大量讀取的額外查詢。作者名稱顯示在每則貼文（高讀），但改名很少（低寫），複製划算。反過來，高頻變動的資料複製多份，每次變動要 fan-out 到所有副本，成本可能超過省下的讀取。

副本數量的可預測性。複製到「一個 user 的 profile 摘要」這種固定副本可控；複製到「該 user 的所有貼文」這種隨資料成長無上限的副本，fan-out 的寫入量會隨規模膨脹，要特別評估。

一致性容忍度。副本短暫不一致（改名後幾秒內舊貼文還顯示舊名）能不能接受。能容忍最終一致的，反正規化的維護可以非同步、用 Cloud Function 慢慢 fan-out；不能容忍的，要嘛同步 fan-out（貴且有規模上限），要嘛這份資料根本不該複製。

配置：fan-out write 維護副本一致

fan-out write 是「一次邏輯更新，寫多個 document」。Firestore 的 writeBatch 讓多個寫入 atomic 提交（最多 500 個操作一批），是固定且可控副本數的標準手段：

 1import { writeBatch, doc, collection, query, where, getDocs } from 'firebase/firestore';
 2
 3// 改名：更新 users/{uid} + fan-out 到該 user 的所有貼文副本
 4async function renameUser(db, uid, newName) {
 5  // 1. 更新權威來源
 6  const userRef = doc(db, 'users', uid);
 7
 8  // 2. 查出所有要同步的副本
 9  const postsSnap = await getDocs(
10    query(collection(db, 'posts'), where('authorId', '==', uid))
11  );
12
13  // 3. batch 提交（超過 500 要分批）
14  const ops = [{ ref: userRef, data: { displayName: newName } }];
15  postsSnap.forEach((p) => {
16    ops.push({ ref: p.ref, data: { authorName: newName } });
17  });
18
19  for (let i = 0; i < ops.length; i += 500) {
20    const batch = writeBatch(db);
21    ops.slice(i, i + 500).forEach((op) => batch.update(op.ref, op.data));
22    await batch.commit();
23  }
24}

這裡的關鍵取捨是同步 fan-out 與非同步 fan-out。上面的同步版本在使用者點「儲存」時就把一千筆貼文改完，使用者等待時間隨副本數成長、且超過 500 要分批多次提交，副本數無上限時會撞到不可接受的延遲。非同步版本把權威來源（users/{uid}）同步更新，副本同步丟給 Cloud Function 在背景慢慢做：

 1// Cloud Function：onUpdate users document 時 fan-out 到副本
 2exports.fanoutUserName = functions.firestore
 3  .document('users/{uid}')
 4  .onUpdate(async (change, context) => {
 5    const before = change.before.data();
 6    const after = change.after.data();
 7    if (before.displayName === after.displayName) return; // 名稱沒變不做
 8
 9    const uid = context.params.uid;
10    const postsSnap = await admin.firestore()
11      .collection('posts').where('authorId', '==', uid).get();
12
13    // 分批 fan-out，背景執行、使用者不等待
14    const docs = postsSnap.docs;
15    for (let i = 0; i < docs.length; i += 500) {
16      const batch = admin.firestore().batch();
17      docs.slice(i, i + 500).forEach((d) =>
18        batch.update(d.ref, { authorName: after.displayName }));
19      await batch.commit();
20    }
21  });

非同步 fan-out 把「使用者體驗的即時性」與「副本的最終一致」分開：權威來源立刻更新、副本最終收斂。代價是中間有一段不一致窗口（改名後到 fan-out 完成前，舊貼文顯示舊名），這對社群 app 的顯示名稱通常可接受。writeBatch 與 transaction 的選擇在這裡也要分清：fan-out 是「寫多個獨立 document、不依賴彼此既有值」用 writeBatch；若更新要依賴讀到的當前值（例如同時扣 A 加 B 且要看當前餘額）才用 transaction，但 transaction 在大量 document 的 fan-out 上不適用。

故障演練：五個副本不一致的 production 踩坑

Case 1：複製了卻沒建 fan-out 路徑

貼文存了 authorName 副本，但改名邏輯只更新 users，沒人寫 fan-out。副本永遠停在建立時的值。修法：反正規化的建模決策必須連同「誰負責同步副本」一起定，複製一份資料就要有對應的 fan-out write 路徑，沒有 fan-out 的副本是一致性債。

Case 2：同步 fan-out 撞到副本數上限

改名時同步更新所有貼文，某個高產出使用者有幾萬則貼文，提交分成幾十批、使用者等了半分鐘還在轉圈、甚至 timeout。修法：副本數無上限的 fan-out 改非同步（Cloud Function 背景做），同步 fan-out 只用在副本數固定且小的場景。

Case 3：fan-out 中途失敗留下部分更新

非同步 fan-out 跑到一半 function 掛了，前 500 筆改了、後面沒改，副本處於半新半舊。修法：fan-out function 要可重入（重跑能補完未完成的），或記錄 fan-out 進度；殘留的不一致由對帳流程掃出修復（對應 1.9 Reconciliation 與 Data Repair）。

Case 4：雙向反正規化造成更新環

A 存 B 的副本、B 也存 A 的副本，改 A 觸發 fan-out 改 B、又觸發 fan-out 改回 A，function 互相觸發成環。修法：反正規化要有明確的權威方向（誰是 source of truth、誰是副本），副本不反向觸發權威來源的更新。

Case 5：把副本當權威來源讀來做判斷

拿貼文裡的 authorName 副本去做權限或業務判斷，而非讀 users 權威來源。副本在不一致窗口內是舊值，判斷出錯。修法：副本只供顯示，任何需要正確性的判斷讀權威來源；明確標示哪個 document 是 source of truth、哪些是顯示副本。

容量與觀測：fan-out 寫入量與不一致窗口

反正規化的容量帳要算 fan-out 的寫入放大。一次邏輯更新放大成 N 次寫入，N 是副本數，這 N 次寫入計入計費。高頻變動 + 高副本數的組合會讓寫入成本失控——這正是判斷「該不該反正規化」的成本面：省下的讀取 vs 放大的寫入。

不一致窗口是要監控的健康指標：權威來源更新到所有副本收斂的延遲。非同步 fan-out 下這個窗口隨副本數與 function 吞吐變動，異常拉長是 fan-out 積壓的徵兆。觀測還要涵蓋 fan-out 失敗率與重試，接回 4.20 Observability Evidence Package。定期跑對帳掃描副本與權威來源的差異，是把潛在不一致從「使用者回報才知道」變成「主動發現修復」，對應 1.9 Reconciliation 的可驗證、可修復、可稽核流程。

邊界與整合：反正規化複雜到該回關聯式

反正規化適合「讀多寫少、副本數可控、能容忍最終一致」的顯示資料。它撐不住的訊號是複製關係長成一張難以追蹤的網——資料被複製到十幾個地方、fan-out 路徑互相依賴、改一個欄位要同步的副本沒人說得清、對帳越來越頻繁。撞到這些訊號時，方向不是把 fan-out 寫得更巧：

• 關聯查詢成為主導需求：當資料的核心價值在「任意關聯與聚合」（報表、跨實體分析），反正規化是在用副本模擬 JOIN，成本與複雜度都不划算。這是 Firestore → 自建 relational 的報表牆——relational 的 JOIN 在查詢時組合，省掉整套副本維護
• 副本維護成本超過查詢省下的成本：高頻變動的資料反正規化，fan-out 放大的寫入成本超過正規化後多查一次的成本，反正規化的前提就不成立
• 巢狀結構保留比拆表更省：相反方向——有些一起讀寫、不需獨立查詢的關聯資料，在 Firestore 用巢狀 map / array 保留在同一 document 反而比拆 collection 簡單，遷到 relational 時用 PostgreSQL JSONB 保留，不是所有東西都要拆成正規表

判讀的起點永遠是 access pattern 與讀寫比，不是「正規化是對的、反正規化是妥協」這種預設立場。在 Firestore 裡反正規化是正解，問題只在它的維護成本何時翻轉。

下一步路由

• 上層：Firestore overview（資料形狀與查詢邊界）
• 資料修復：1.9 Reconciliation 與 Data Repair（副本不一致的對帳與修復）
• 狀態歸屬：1.8 State Ownership 與 Query Boundary（權威來源與派生副本的分辨）
• 遷移 driver：Firestore → 自建 relational（報表牆與反正規化還原）
• 官方：Firestore data model、Batched writes

本文是 Cloud Spanner overview 的 concept-layer deep article。Overview 已說明 Spanner 在強一致 SQL 譜系的定位、本文聚焦 consistency model — 三個常被混用的概念（external consistency / serializability / linearizability）的精確差異、line-rate scaling 對照、跟 cross-region quorum 的物理硬限。

問題情境：五個詞混用的選型困境

團隊在 Spanner / CockroachDB / Aurora DSQL 之間選型、看文件講 strict serializability、external consistency、linearizable、snapshot isolation、serializable — 五個詞混用、不確定買的是哪一種保證。讀者徵兆通常是「我們需要強一致」但說不出強到哪、把 serializable transaction 跟 linearizable read 當同一件事、debug 對帳時發現「兩個 transaction 都 commit 成功、順序卻違反 user 體感」。

真實壓力場景：金融帳本 — A 在台北轉帳給 B、B 在東京立即收到通知然後查餘額、結果查到「轉帳前」的餘額。serializable 允許這種行為（兩 transaction 可以排成任意順序、不要求跟 wall clock 一致）、external consistency 不允許（必須等 commit 後的順序符合 real-time）。混用兩個詞會讓選型結論在系統實作後才被推翻、那時候改架構成本已經高了。

Case anchor：9.C10 Cloud Spanner planetary scale — Google Ads 計費需要 external consistency；對照 PostgreSQL SSI、CockroachDB HLC、Aurora DSQL。dogfood 邊界明示：9.C10 是 Google 內部 dogfood case、不是 customer-facing capacity 參考；本文引用其 line-rate scaling 數字時要附「Google internal dogfood 揭露的設計目標、不是客戶 SLA」邊界。

三個概念的精確定義

Serializability

transaction 的執行結果等同於 某個 序列順序執行；不要求順序跟 real-time 一致。PostgreSQL SERIALIZABLE isolation level（SSI 實作）給的就是這個保證。它解決的問題是 concurrent transaction 之間互相干擾的 anomaly（dirty read / lost update / write skew / G2-item）、不解決「跨 transaction 的 wall-clock 順序」。

範例：A 在 10:00:00 commit T1（餘額 +100）、B 在 10:00:01 commit T2（查餘額）。serializable 允許系統把 T2 排在 T1 之前、B 看到舊餘額 — 兩 transaction 都成功、isolation 沒被破壞、但用戶體感違反順序。

Linearizability

單一 object 操作有全序、且全序跟 real-time wall-clock 一致。只談 single-object、不談跨 object transaction。DynamoDB strongly consistent read 是 single-item linearizability、Redis INCR 是 single-key linearizability。對應 linearizability 卡。

linearizability 跟 serializability 是 正交 的兩個概念 — linearizability 講「單一 object 的 real-time 順序」、serializability 講「transaction 的 anomaly-free 執行」。一個系統可以是 linearizable 但不 serializable（單 object 強保證、跨 object transaction 沒有）、也可以是 serializable 但不 linearizable（PostgreSQL SSI single-node 在 replica lag 後就不 linearizable）。

External consistency / Strict serializability

transaction 層級的 serializability + 全序跟 real-time 一致 — 等同於把 linearizability 推廣到 multi-object transaction。Spanner 用 TrueTime + commit wait 實作、保證 commit timestamp 順序 = real-time 順序。對應 external-consistency 卡。

回到金融帳本例：external consistency 不允許 T2 排在 T1 之前、因為 T2 的 transaction timestamp 必須大於 T1 的 commit timestamp、用戶查餘額必看到 +100 後的金額。

Line-rate scaling 對照：為什麼 PG serializable 在 multi-node 拿不到 line-rate

這段的核心責任是回答「為什麼 Spanner 不只是『更強的 serializable』、是『coordinator 換拓樸』的 paradigm shift」、扣 truetime-api-depth 的商業邏輯先行 frame。讀者選 consistency 等級時、實際在選「系統的 scaling 路徑」、不只是「應用層 anomaly 哪些被排除」。

9.C10 揭露的線性擴展數字

「2 nodes → 45K reads/sec、4 nodes → 90K reads/sec」這條線性 scaling 揭露 Spanner external consistency 不是「加強版 serializable」、是把跨節點 coordinator 從 single-point 換成「拓樸感知的多 leader（每個 split 自己的 Paxos group）」、所以擴 node 數可以線性拿 throughput。

Dogfood 邊界明示：9.C10 數字是 Google internal dogfood、不是 customer-facing capacity 承諾。客戶能拿到的 line-rate 受 instance config、region layout、workload shape 影響、不會自動複製 Google 內部曲線。

對照表：四個系統的 scaling 路徑

每個欄位都要回到具體的 scaling 機制讀。PostgreSQL SSI 跟「single-primary」綁定 — 想 scale write 只能 sharding；CockroachDB 把 range 拆細、coordinator 分布到 range 層、但跨 range conflict 還是會 trigger retry；Spanner 用 Paxos group per split、commit timestamp 用 TrueTime 對齊、不需要全局 coordinator 來決定順序；Aurora DSQL 是新系統、機制細節隨版本演進。

為什麼這個對照寫進 consistency 文章、不是純機制文章

讀者選 consistency 等級時、實際在選「系統的 scaling 路徑」、不只是「應用層 anomaly 哪些被排除」。external consistency 的 cost 包含 commit wait latency、但 benefit 包含 line-rate scaling — 兩者要一起講、不能拆開。把對照表放這裡、讓 consistency 跟 scaling 在同一段被讀者一起判讀、避免「我們需要強一致」這種需求被翻譯成「升級到 Spanner」這種跳號決策。

Cross-region quorum 100-200ms 物理硬限：強一致 + 全球不是免費

Cross-Region Quorum + external consistency + multi-region 不是「免費全球」、是「用 latency 換 consistency」。讀者若沒看到具體數量級、會誤把 Spanner 當作「強一致 + 全球 + 低延遲」的奇蹟、實際 cross-region write 在物理光速硬限下必須付跨洲 round-trip cost。

9.C10 揭露的數量級

「external consistency 必須等多區 quorum、跨洲交易延遲可達 100-200ms」 — 這是 9.C10 case 直接揭露的工程數字、不是本章 derive。Dogfood 邊界明示：9.C10 case 揭露的是 Google internal dogfood 觀察到的數量級、不是 SLA 承諾；實際客戶的 cross-region write latency 隨 voting region 配置、network path 變化。

Latency 拆解模型（cross-region write）

1total write latency ≈ 2ε（[Commit Wait](/backend/knowledge-cards/commit-wait/)、TrueTime ε 兩倍 ≈ 2-14ms）
2                    + quorum RTT across voting regions
3                       跨洲：50-100ms one-way、來回 100-200ms
4                       跨大陸內：10-30ms
5                       跨 zone（同 region）：< 5ms
6                    + Spanner internal processing

跨洲 quorum 在這個模型裡是 dominant term、不是 commit wait — 判讀時要明示「commit wait 跟跨 region quorum 是兩個獨立的物理 cost、不能混用一個 latency 數字解釋兩者」。讀者常見的誤解是把 100-200ms 寫成「Spanner commit wait」、實際 commit wait 只是其中 2-14ms、剩下 100ms+ 是物理光速限定的 quorum RTT。

Scope warning：實際 latency 依 region 配置

100-200ms 是 9.C10 case 揭露的範圍、實際 latency 隨 voting region 配置變化：

引用要附條件「跨洲多 region instance、實際數字依 region 配置」、不能寫成「Spanner cross-region write 一律 100-200ms」。讀者拿這條 latency anchor 做 capacity planning 時、必須先 audit 自家 instance 是哪種 config、不能套用 100-200ms 當基線。

SSoT 對齊：Strong + multi-region 互斥議題不在此處展開

Strong consistency + multi-region 互斥議題（包含 Cosmos DB 5 levels 的 Strong + multi-region 限制）的 SSoT 是 Cosmos DB multi-region-write-conflict。本篇 cross-link 不展開、避免重複展開同議題。

本篇展開的子議題：

• external consistency / serializability / linearizability 的精確定義差異
• Spanner external consistency 的 TrueTime 實作機制（細節在 truetime-api-depth）
• cross-region quorum 的物理 cost 數量級
• line-rate scaling 對照表（為什麼 single-primary 系統拿不到線性）

兩個 SSoT 處理同一個讀者問題（強一致 vs multi-region）的不同切面 — 本篇從 系統 scaling 路徑 切入、Cosmos DB 文章從 consistency level 選擇 切入。讀者讀完本篇後若還在問「為什麼 Cosmos DB strong consistency 不能配 multi-region write」、跳 Cosmos DB SSoT。

操作流程：怎麼驗證 consistency 等級

決策樹

1跨 multi-object transaction 嗎？
2├─ 否 → DynamoDB linearizable read / Redis single-key 足夠
3└─ 是 →
4   跨 region 寫入嗎？
5   ├─ 否 → CockroachDB / PostgreSQL serializable 足夠
6   └─ 是 →
7      real-time 順序是產品契約嗎？
8      ├─ 否 → CockroachDB multi-region 可接受
9      └─ 是 → Spanner / Aurora DSQL

驗證 consistency 等級的方法

跑 Jepsen-style test、寫 read-write workload 跑 anomaly checker、量 dirty write / lost update / write skew / G2 anomaly。production 系統若不能跑完整 Jepsen、至少要在 staging 跑 對應 anomaly 的具體 test case — 例如金融帳本跑「轉帳後立即跨 region 查餘額、能不能看到舊值」這個具體 case、不是只看 isolation level 設定文字。

SDK 層的選擇點

1Spanner          → 預設就是 external consistency、read 可降到 bounded staleness
2CockroachDB      → 預設 serializable、可選 AS OF SYSTEM TIME 換 stale read
3PostgreSQL       → 要顯式 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
4DynamoDB         → 預設 eventually consistent、ConsistentRead=true 換強一致

每個 SDK 的 default 都不同、不能假設「沒設就是強的」。PostgreSQL default 是 READ COMMITTED、write skew 直接漏。

Rollback boundary

若一致性等級從強降到弱、要審計應用層所有讀取點（特別是「讀後決策再寫」的 critical path）。降級不是 config 一行的事、是 audit 一遍應用層假設的事。

失敗模式：把 transaction 當「強一致」的五種誤用

把「我們用 transaction」當「強一致」

transaction 只保證原子性、不保證 isolation level；預設 isolation 可能是 READ COMMITTED、write skew 直接漏。修法是顯式設定 isolation level、跑對應 anomaly test 驗證、不靠「我們用 transaction」這種口頭契約。

假設 single-node serializable = distributed serializable

PostgreSQL SSI 跨 read replica 立刻失效（replica lag）、團隊以為加 replica 還是 serializable。實際 replica 的 read 是 eventually consistent、可能看到舊 snapshot。修法是區分 primary read vs replica read、replica read path 標 bounded staleness、不混用 isolation level 字眼。

跨系統 timestamp 假設

service A 用 Spanner、service B 用 Redis、用各自 timestamp 重組事件順序 — service B 的 clock 沒 TrueTime 保證、跨系統 external consistency 不成立。修法是跨系統事件順序要走 單一系統的 timestamp 或 event sequence number、不靠各系統自己的 wall-clock 拼出順序。

把 linearizability 跟 strong consistency 混用、忽略 multi-object 場景

DynamoDB strongly consistent read 是 single-item linearizability、不等於跨 item transaction 強一致。團隊以為「我用了 strongly consistent read 就 OK」、實際跨 item 的順序保證沒有。修法是區分 single-object vs multi-object、跨 item 邏輯如果有順序需求、要用 DynamoDB transaction API（付 2x WCU 的 cost）或換到 Spanner。

過度承諾 external consistency

dashboard / analytics 強寫 strong read、付不必要的 latency tax。修法是把 read path 分類、analytics / reporting 改 bounded staleness、保留 strong read 給 critical path。回 truetime-api-depth 的「把 strong read 用在不需要的路徑」失敗模式。

容量與觀測：一致性等級的 latency 量化

跨 region 延遲量化（finding F3.15、來源 9.C10）：external consistency + multi-region instance config、跨洲 quorum 把 write latency 推到 100-200ms 數量級；單 region instance 的 commit wait 是 baseline（≈ 2ε ≈ 2-14ms）、跨 region quorum 是額外 dominant cost。

Cloud Monitoring：spanner.googleapis.com/instance/clock_skew_ms 觀察 ε、api/api_request_latencies for Commit 觀察 commit latency 分布；CockroachDB 觀察 sql.txn.restart.serializable 計數（serializable restart 率）。回到 4.20 Observability Evidence Package 把一致性等級當 release gate 的一部分。

Capacity 觀點：external consistency 的 commit wait 是「無法 scale away 的 latency 支出」、capacity planning 要先扣這部分；跨 region instance 的 quorum RTT 也是物理硬限、不能透過加 node 解。

邊界與整合：sibling 路由跟 anti-recommendation

Sibling deep articles

• truetime-api-depth：external consistency 的硬體基礎、TrueTime ε / commit wait 數學、商業邏輯先行 frame
• schema-migration-interleaved-tables：schema change 的版本一致性也用 TrueTime
• migrate-from-cloud-sql-pg：Diff 階段要明確標示一致性等級從 SSI 升到 external consistency 的應用層影響

SSoT cross-link

Strong consistency + multi-region 互斥議題的 SSoT 在 Cosmos DB multi-region-write-conflict、本篇不重複展開。

跟 1.x 章節的互引

• 1.11 全球分散式 OLTP：Spanner 是 PC 系統的代表
• transaction boundary：跨 transaction 順序保證

Knowledge card 雙引用

• linearizability — 本文當這張卡的 vendor 應用範例
• external-consistency — 本文擴展這張卡的實作機制
• isolation-level — 本文澄清 isolation level 跟 consistency model 的差異

Anti-recommendation

讀者讀完本文應該能判斷：「我們需要強一致」不等於「升級到 Spanner」 — 先問是 single-object 還是 multi-object、是 single region 還是 multi region、real-time 順序是否是產品契約。多數 OLTP workload 用 PostgreSQL serializable 已經夠、為 external consistency 付 GCP lock-in + 跨 region quorum cost 的判準很高。

本文不重複 MongoDB vendor overview 已寫過的 replica set 簡介 — 而是 production 部署 + 跨層協作 + 失敗修復的實作層教學。

進本文前先確認 MongoDB 已通過適配判讀：workload 是否落在 MongoDB 適用區（document shape 主導 / contract layer 該放哪 / 跨雲 hedging 是否需要）— 判讀軸見 schema-design-pattern 開頭 3 軸前置判讀。Read scaling 是 已選 MongoDB 後 的容量決策、判讀通不過時 read preference 修補無法救回 vendor 選錯。

問題情境：read scaling 撞牆的兩種長相

典型觸發場景：primary 寫入飽和、TL 提議「讀都打 secondary」想橫向擴容。改完後幾個 production 徵兆連環出現：

• User 看到「我剛下的訂單怎麼還沒出現」— write 進 primary、立刻 read 打 secondary、secondary 還沒 apply 該寫入、user 看到 stale data
• 跨 region replica set：app server 在 Tokyo、primary 在 Singapore、每筆讀走 70ms 跨海 RTT；改 nearest 後 latency 降但 stale read 出現
• Replication lag 在 backup 期間飆到分鐘級、secondary read 拿到幾分鐘前的資料、前端報表時間軸對不上
• Failover 期間 read preference 沒寫好、client 一直連舊 primary、SocketTimeout 直到 driver retry 邏輯介入

第二類議題、規模更大：把所有 read 打 secondary、replica 數量加到 5-7 仍撐不住 sustained 高 read（>500K reads/sec）；replication lag 升 + secondary CPU 飽和。這時 read preference 已不夠、必須加 cache + 跨層 freshness 機制。

讀者徵兆：rs.printSecondaryReplicationInfo() 顯示 lag 分鐘級、application log 出現「我剛寫的資料讀不到」客訴、failover 演練後 connection error 持續 30s+、cache hit rate 跟 read latency 反向相關。

Case anchor：9.C36 Coinbase 揭露「document model 撐 1.5M reads/sec 靠 cache + freshness token」、含警示「1.5M reads/sec 是 users 服務 加上 cache 的數字、不是 MongoDB cluster 純讀取數字」。跨 region read preference 改 nearest 後 stale read 的具體 incident 細節需未來 case 補完、本文以「常見 failure pattern」處理。

核心機制

MongoDB read preference + read concern 兩軸

Read preference 五種：

• primary（預設）：只打 primary、強一致、primary 飽和時無路可走
• primaryPreferred：先 primary、primary 不可用 fallback secondary
• secondary：只打 secondary、永遠拒 primary、failover 期間若所有 secondary 都不行就拋錯
• secondaryPreferred：先 secondary、secondary 不可用 fallback primary
• nearest：不是「最近的 secondary」、是「ping latency 最低的 member」（可能是 primary）；driver 用 latency window（預設 15ms）內隨機挑

Read concern 是另一軸：

• local：讀本地最新（含未確認）、效能最佳、可能讀到後來 rollback 的資料
• available：跟 local 類似但對 sharded cluster 有差異
• majority：讀到「已寫到多數 member」的資料、寫入 commit 後在多數 member 確認後才看得到
• linearizable：強制最新、必須打 primary、最高 latency

Write concern w: "majority" 保證寫入確認後在多數 member 上、但不保證 secondary 馬上 visible — 兩個概念分開。

Causal consistency session（DB 層機制）

Causal consistency session 解的是 單 client 在 MongoDB cluster 內部 的因果一致：

• Client session 帶 clusterTime + operationTime
• Driver 把 read 路由到「已 apply 該 operationTime」的 member
• 實現 read-your-own-write（自己剛寫的、自己讀得到）

機制只在「同一 client session」內生效。跨 client 的因果一致（A 寫 → B 讀）不在範圍內。

其他輔助機制：

• Tag set：member 標 {region: "ap-tokyo", role: "analytics"}、read preference 帶 tag 把流量路由到特定 member
• Hidden / delayed secondary：不參與 election、不接 client read、做 backup / DR 用
• Election：primary 失聯後 majority 投票選新 primary、預設 10s 內完成；election 期間所有 primary read 失敗

Freshness token（cache 層機制）

9.C36 Coinbase 揭露的 跨層 機制 — 解的是 MongoDB + cache 跨層 的 read-after-write、不是 cluster 內部。對應 Freshness Token 卡片的 application-level 版本協議定義：

觸發條件：直接打 MongoDB 不可能撐 1.5M reads/sec（口徑：users 服務應用層觀察、含 cache、非 MongoDB cluster 純讀取）。Coinbase 在 users 服務前加 Memcached query cache、單 document query 先查 cache。

跨層一致性問題：write 進 MongoDB primary、cache 還是舊資料、client 下次 read 從 cache 拿到舊版。

freshness token 機制：

1. Write 成功後、server 給 client 一個 token（包含 OCC version / clusterTime）
2. Client 之後 read 帶這個 token
3. Server 保證返回的資料版本 ≥ token
4. 若 cache 的版本 < token、bypass cache 直接打 DB

跟 causal consistency session 的關係：兩者解決同一類問題（read-after-write）但作用範圍不同。Causal session 是 DB 層、保證在同一 cluster 內 read-your-own-write；freshness token 是 DB + cache 兩層共用的版本協議、保證跨層 read-your-own-write。

跨層協作三選一

讀者真實系統的 read 一致性需求要選哪層處理：

對應 knowledge card：stale-read、replication-lag、session-consistency、eventual-consistency。

操作流程

Step 1：read shape 分類。把所有 read 分成四類：

• (a) 強一致必須 read-your-own-write（訂單詳情、帳戶餘額）
• (b) 容忍秒級 lag（個人資料、商品詳情）
• (c) 容忍分鐘級 lag（報表、analytics）
• (d) 大規模 read scaling 需 cache + freshness token（用戶資料 / 高頻 product query）

Step 2：依分類對映機制。

Step 3：driver config（Node.js / Java / Python 都類似）：

1mongodb://host1:27017,host2:27017,host3:27017/db?
2  replicaSet=rs0&
3  readPreference=secondaryPreferred&
4  readPreferenceTags=region:ap-tokyo&
5  readPreferenceTags=&
6  maxStalenessSeconds=90&
7  readConcernLevel=majority

readPreferenceTags 寫多個 = fallback chain（先 tokyo 失敗 fallback 任意）。maxStalenessSeconds=90 拒絕 lag > 90s 的 secondary。

Step 4：causal consistency session：

1with client.start_session(causal_consistency=True) as s:
2    coll.insert_one(doc, session=s)
3    # 下面這個 find 自動路由到能讀到剛才寫的 member
4    coll.find_one({"_id": doc["_id"]}, session=s)

Session 結束後因果關係結束、下個 session 不繼承。

Step 5：freshness token 設計（9.C36 Coinbase 模式）：

• Write API 返回 {result, version_token} — token 含 OCC version 或 MongoDB clusterTime
• Read API 接受 optional If-Version-≥ header / parameter
• Cache lookup 比對 cache entry version 跟 token、低於 token 就 invalidate + bypass 到 MongoDB
• DB 層 read 用 readConcern: "majority" 保證返回的 version ≥ token

Step 6：staging 驗證。灌入 replication lag（暫停 secondary apply）驗證 application 行為；灌入 stale cache 驗證 token bypass 邏輯；模擬 failover 驗證 driver retry。

驗證點：

• rs.printSecondaryReplicationInfo() lag < SLO
• driver metric readPreferenceUsageCount 分布符合預期
• failover drill 後 read recovery < 15s
• cache hit rate vs freshness bypass rate 比例監控

Rollback boundary：read preference 是 driver-side config、可以 hot-swap；causal consistency session 需 application code 改、需灰度；freshness token 是 application + cache + DB 三方協議、回退需協調。

失敗模式

Read-after-write 不一致（DB 層）：寫 primary → 立刻 secondary read、應用 race condition 顯示「資料消失」。修法是 causal consistency session、driver 自動路由到已 apply 該寫入的 member。

Read-after-write 不一致（跨層）：寫 primary → cache 還是舊資料 → user 看到舊資料。causal session 解不了（cache 在 MongoDB 外）、必須走 freshness token 跨層協議。

Stale read 在 lag 高峰：backup / DDL / 大量寫入導致 secondary lag 分鐘級、secondary read 拿到舊資料。修法設 maxStalenessSeconds 拒舊 member、driver 自動轉到較新的 member 或 primary。

nearest 在跨 region 不穩：latency 抖動讓 driver 在 primary / secondary 跳、寫一致性與 read latency 同時惡化。修法是不要用 nearest 解跨 region 議題、應該用 tag set 明確路由。

Failover 期間 primary read 全失敗：election 10s 內所有 primary read 拋錯。修法改 primaryPreferred + driver retry 邏輯吃掉短暫失敗、application 端配 retry policy。

Tag set 失準：把 region: "ap-tokyo" 的流量路由到 tag 為 tokyo 的 member、但該 member 故障時沒 fallback、流量直接停。修法是 tag 設多層 fallback chain、最後一層留空 tag 表示「任意 member」。

Analytical query 跑 OLTP secondary：secondaryPreferred 把報表打 OLTP secondary、報表 query 拖垮 OLTP read latency。修法是 analytical workload 用 tag set 路由到專屬 analytics secondary、跟 OLTP read 隔離。

Freshness token 漏寫：write 沒帶 token 給 client / client 沒帶 token、token 機制 silently 失效、read 走 cache 拿舊資料。修法 token 必須 e2e 強制（middleware 自動帶 / 自動驗證）、不能靠 application 自覺。

Cache bypass 比例失控：所有 read 都 bypass cache、cache 等於沒裝。修法是 token 失敗率要監控、過高表示 cache invalidation 設計有問題（cache 沒在 write 後 update / invalidate）。

Anti-recommendation：

• read-heavy 但有強一致需求的場景不要為了 scale 改 secondary read；該換 SQL + read replica 加 application-level cache、或加 sharding 把 primary 寫散開
• 大規模 OLTP（>500K reads/sec）想單靠 MongoDB read preference 撐 = 拿不到那個量級。Coinbase 案明示「直接打 MongoDB 不可能撐 1.5M reads/sec」、必須 cache + freshness token

容量與觀測

關鍵 metric：

• Replica health：每個 member 的 opcounters 分布、rs.status().members[].optimeDate 推算 lag
• Read preference 命中：driver-side readPreferenceTags 命中率
• 一致性 SLO：stale read 比例（causal consistency 拒絕重試次數）
• 跨層 freshness：cache hit rate vs freshness bypass rate

Mongo command：

• rs.status()：replica set 整體
• rs.printSecondaryReplicationInfo()：lag 概況
• db.serverStatus().repl：詳細 replication metric
• db.adminCommand({replSetGetStatus:1})：完整 status

Application observability：APM 看「同一 session 內 write + read 順序對 latency / error 的影響」、SLO 是 read-your-own-write 命中率；跨層還要看 freshness token 流動完整性（write 是否發 token、read 是否帶 token、cache 是否驗 token）。

Lag alarm：lag > 30s 預警、> 90s 觸發 driver maxStalenessSeconds 自動拒讀。

回到 4.20 observability evidence：把 read preference 命中分布、replication lag time series、failover drill recovery time、freshness token bypass rate 列為 evidence。

回到 9.5 bottleneck localization：read latency 異常時要區分 (a) primary 飽和 (b) secondary lag 高 (c) tag routing 把流量集中到單一 member (d) cache hit rate 下降 / bypass 率上升。

邊界與整合

Frame 5：合規邊界 — MongoDB 用 cluster-per-region 吸收

MongoDB / Atlas 沒有 row-level locality 機制（不像 CockroachDB 可把單 row pin 在合規 region）— 跨境合規必須以 cluster-per-region 拓樸吸收：每個合規市場開獨立 cluster、application 層做 routing、不靠 replica set / sharded cluster 機制跨 region。

跨 vendor 對照：

MongoDB 在這 frame 的退化點：read preference 機制本身不解合規 — 即使 readPreferenceTags={region:eu} 把流量路由到歐洲 secondary、但 primary 在亞洲時跨境 replication 仍在跑、合規 audit 不會放行 路由層 控制當作 資料邊界 控制。合規市場必須整 cluster 分離、再用 application 層 routing 把 user 帶到對應 cluster。

Atlas 在合規場景的 fit：Atlas global cluster（zone sharding 把 shard 鎖在 region）是「跨 region 但 資料 pin 在 zone」的中介選項、適合 GDPR 軟條款（資料在歐洲 EEA 內可流動）；strict 條款（資料不能離開單一國家）仍須走 cluster-per-region。

Sibling 與 cross-link

Sibling deep articles：

• shard key selection — read preference 解決不了 write 飽和、要切 shard
• change streams + Kafka — change stream 預設打 primary、放 secondary 的 trade-off
• aggregation pipeline optimization — 把 analytical aggregation 路由到專屬 secondary
• connection management and cache layer — freshness token 是該篇的核心議題之一、本文聚焦 DB 層 vs cache 層機制對照、不展開 cache 部署架構

Migration playbook：

• 跨 region 強 consistency 需求 → → Cosmos DB MongoDB API（5 consistency level）
• 跨 region 想保留原生 MongoDB → → Atlas global cluster

跟 1.x 互引：1.1 高併發資料存取 處理 read scaling pattern；1.11 全球分散式 OLTP 處理跨 region 一致性升級路徑。

相關連結

• MongoDB vendor overview — 本文是該頁尾「replica set + read preference」backlog 的深度展開
• Vendor 深度技術文章方法論
• 9.C36 Coinbase — freshness token + 1.5M reads/sec（含 cache）
• 官方：MongoDB Read Preference、Read Concern、Causal Consistency

本文不是 Cosmos DB overview（請看 Cosmos DB vendor 頁）— 而是 consistency level 工程選擇邏輯 的深度展開。Case anchor 是 9.C11 Minecraft Earth（用 session consistency 撐 AR 全球同步、5 level 跨 collection 分流）+ 9.C21 ASOS（Black Friday 用較弱 consistency 換 throughput）。

Cosmos DB workload 適配判讀（四層 framing）：API model 三型遷移路徑 / RU 思維轉換成本 / multi-model 差異化是否真用上 / 跨雲 hedging vs 單雲 lock-in — 判讀軸詳見 mongodb-api-vs-sql-api 開頭四層 framing。本文聚焦 consistency level 選擇操作層、是 已選 Cosmos DB 後 的 read / write 語義決策；若 workload 不適用 Cosmos DB、level 選擇無法救回 vendor 選錯的取捨。

問題情境

典型觸發場景：team 啟動 Cosmos DB account、setup wizard 問「預設 consistency level」 — 5 個選項、文件講概念、不知道實際業務該選哪個。production 上線後使用者反映「加入購物車後立刻看『我的購物車』讀到舊狀態」、「跨 region 看到玩家瞬移回舊位置」 — debug 發現是 consistency level 沒選對。

讀者徵兆：

• 「Session 跟 Eventual 看起來差不多、為什麼 Session 是預設」
• 「Bounded staleness 的 K 跟 T 該設多少」
• 「Strong 在 multi-region account 為什麼有額外限制」
• 「跨 region read 拿到舊版本、是 consistency 設錯還是 partition key 問題」

真實壓力：

• 購物車場景：加入購物車後立刻看「我的購物車」、結果讀到舊狀態（user 體驗破洞）
• 遊戲場景：玩家位置同步、跨 region 看到「玩家瞬移」回舊位置（遊戲體驗 bug）
• 金融場景：跨服務寫入後立即 read confirm、看不到剛寫的 — 業務邏輯誤判「沒寫進去」、重試 / rollback

consistency level 選錯不是 config 問題、是 影響 user-facing 行為 的 selection 決策、必須在 selection 階段釐清。

核心機制：5 個 level 的精確語義

Strong

• 機制：read 拿到最新 commit、提供 linearizable read
• 限制：single-write region 限制；multi-region write 不可同時用 Strong（時間敏感 claim、查 最新文件）；跨 region 配 Strong 還要付 Cross-Region Quorum 的物理 latency tax（跨洲 100-200ms）
• 適合：金融交易、庫存扣減、status 機器寫後 read confirm
• 為什麼互斥：詳見 multi-region-write-conflict 的 AP 取捨段、本篇不展開

Bounded staleness

• 機制：read 落後 不超過 K 個 version 或 T 秒（取較嚴格者）；單 region 內 linearizable、跨 region 有 bounded lag、跟 Freshness Token 是兩種「跨層 read-after-write」協議的選擇（前者 vendor 內建、後者 application-level）
• 設定：K（version 上限）+ T（時間上限）兩個參數
• 適合：multi-region 但需要「有 bound 的 staleness 保證」、如 trading system 跨 region read with SLA

Session（預設、最常用）

• 機制：同一 session token 內讀寫一致；session 之外 eventual
• 適合：多數互動式產品的甜蜜點 — 使用者寫入後自己立刻讀得到、其他 session 可接受 eventual
• 為什麼是預設：cost 接近 eventual（不像 Strong 多 2x RU）、體驗接近 Strong（自己讀寫一致）— 是 trade-off 的甜蜜點

Consistent prefix

• 機制：read 不會看到亂序的寫入（看到 A→B→C、不會看到 A→C→B）、但可能落後
• 適合：時序敏感但可 stale 的場景（如新聞 feed 不能跳序、但可以晚幾秒）
• 風險：常被誤用為 Session 替代、跨 session 一樣 stale、但比 Eventual 多保證 順序

Eventual

• 機制：最便宜、無順序保證
• 適合：完全可 stale + 不需順序的場景（分析、log 聚合、推薦系統）

跟 Cosmos DB account / container 的關係

• account 預設一個 level
• 單一 request 可以 降級（讀更弱 level）、不可升級（讀更強）
• container 層 無法獨立設定 consistency level（時間敏感、查最新文件）— 分流靠 collection 切分 + per-request override

RU 成本差異

• Strong / Bounded read ≈ 2x Session / Eventual 的 Request Unit
• write 成本不直接受 read level 影響、但 multi-region replication 開銷會（每多一個 region、寫成本 ×N）
• selection 階段要把 consistency level 當「RU 倍數」進入容量公式、見 ru-cost-model-sizing

跟通用 consistency 卡片的對應

Cosmos DB 是 少數把 5 level 都商品化 的服務、其他系統通常只給 2-3 級（MongoDB read concern majority / local / linearizable、DynamoDB strong / eventual）。對應 consistency-level 卡片的概念分層。

跟 linearizability 的關係：Cosmos DB Strong = single-region linearizable、不是 跨 region external consistency（跟 Spanner 的 TrueTime + Paxos 不同）。這個區別是 selection 階段的常見誤判 — 別把 Cosmos DB Strong 當成 Spanner 替代品。

對應 knowledge cards：consistency-level / linearizability / stale-read。

進階設計策略：同一 application 內不同操作選不同 level

9.C11 Minecraft Earth 案例的平台特性段揭露「一致性是 spectrum、不是 binary」 — AR 遊戲玩家位置稍 stale OK（用 session / eventual）、庫存交易需要 strong；同一 application 內不同 collection / container 配不同 consistency 是進階策略、不一定是 account 一刀切。

container 層無法獨立設定 consistency level（時間敏感、查最新文件）、所以分流靠：

• Collection / container 切分：高一致需求的資料放獨立 account、預設 Strong；低一致需求放另一 account、預設 Session
• Per-request override：account 預設 Session、特定「寫入後立即讀」場景升 Bounded、批次分析降 Eventual；用 SDK 的 RequestOptions.ConsistencyLevel

Per-request override 範例（C# SDK）

 1// account 預設 Session
 2// 但這個 read 需要 Bounded staleness
 3var response = await container.ReadItemAsync<Item>(
 4    id: "item-123",
 5    partitionKey: new PartitionKey("user-456"),
 6    requestOptions: new ItemRequestOptions {
 7        ConsistencyLevel = ConsistencyLevel.BoundedStaleness
 8    });
 9
10// 批次分析、降到 Eventual 換成本
11var queryOptions = new QueryRequestOptions {
12    ConsistencyLevel = ConsistencyLevel.Eventual
13};
14var iterator = container.GetItemQueryIterator<Item>(query, requestOptions: queryOptions);

注意 不可升級 的限制：account 預設 Eventual、per-request 不能升 Strong（會 error）。要保留升級彈性、account 預設應該是 最強需要的 level、再 per-request 降級。

跟 partition-key-design 的關係

partition 失衡時即使設 Strong consistency 也看到 throttle、application 看到的是 429 retry 後的高 latency、不是 stale data — consistency level 跟 partition key 共同決定 真實一致性體驗。partition skew 把 Strong 的 SLA 拉到比 Session 還差、見 partition-key-design 的 latency budget 拆解段。

操作流程

account 層設定

1# Portal / ARM template / CLI
2az cosmosdb update --name mycosmos --resource-group myrg \
3  --default-consistency-level Session

切換 level 是即時生效、但 production 切換需要 audit 所有 client 的 session 邏輯（特別是 Strong → Session 的降級會讓「跨 session read 變 stale」）。

Request 層 override

SDK 傳 RequestOptions.ConsistencyLevel（C# / Java / Node SDK 行為一致）。注意 只能降級、升級會 reject。

Session token 管理

每個 read response 帶 session token、client 下次 read 帶回去；跨 service 共享 token 需要顯式傳遞（不然每個 service 自己一個 session）。

 1// 拿到 session token
 2var response = await container.ReadItemAsync<Item>(id, pk);
 3var sessionToken = response.Headers["x-ms-session-token"];
 4
 5// 跨 service 傳遞（如 HTTP header）
 6httpClient.DefaultRequestHeaders.Add("X-Cosmos-Session-Token", sessionToken);
 7
 8// 下游 service 取得 token、用在 SDK request
 9var requestOptions = new ItemRequestOptions { SessionToken = sessionToken };
10var downstreamResponse = await container.ReadItemAsync<Item>(id, pk, requestOptions);

驗證 level 行為

寫入後立即 read 同 partition key、量 staleness window。用 Cosmos DB Diagnostic Log 看 request 的實際 consistency level；對照 SDK 設定確認沒被預設 override。

Rollback boundary

account 預設可改、但 production 切換 level 需要 audit 所有 client 的 session 邏輯；container 層無法獨立設定（時間敏感、查最新文件）。

失敗模式

Failure 1：全用 Strong consistency

互動式產品 Session 即足夠、用 Strong 浪費 2x RU + 限制 multi-region write、cost 暴漲且 multi-region 配置受限。徵兆是「RU consumption 明顯偏高、且 multi-region write 開不起來」 — 才發現預設選 Strong。

修：

• 盤點業務需求、絕大多數讀寫場景 Session 就夠
• 把需要 Strong 的少數 collection 拆獨立 account、其他 default Session
• 計算 cost：Session vs Strong 在多數 workload 差距 1.5-2x、長期成本顯著

Failure 2：Session token 沒回傳

read 後拿 token、下次 read 沒帶、實際變 Eventual；徵兆是「自己的寫立刻 read 看不到」、debug 才發現 SDK 設定漏。SDK 預設會自動管理 session token、但跨 service 傳遞時容易漏。

修：

• 同一 service 內用 SDK 預設行為、不要關 session token cache
• 跨 service 通信時把 session token 隨 HTTP header 傳遞
• 或改 account 層 Bounded staleness（提供跨 session 的 K/T bound、不依賴 token）

Failure 3：跨 service 共享 session 假設

service A 寫、service B 讀、B 沒拿到 A 的 session token → 看不到 A 的寫。常見場景：order service 寫訂單、notification service 立刻 read 訂單寄通知 — notification 沒拿到 order 的 token、讀到舊狀態（或讀不到）。

修：

• service A 寫完、把 session token 進 message（Kafka event / HTTP response）傳給 B
• B 用 token 做 read、保證讀到 A 的寫
• 或業務上接受 eventual、design notification 有 retry / reconcile 機制

Failure 4：Bounded staleness 設太鬆

K = 100,000、T = 1 hour、實際等於 Eventual、team 以為自己有保護。bounded staleness 的 K/T 要對應業務 SLA、不是 vendor 預設值。

修：

• 根據業務 read-after-write SLA 設 T（如「5 秒內必須讀到」設 T=5）
• K 通常設成「peak QPS × T」的合理倍數
• 量測：production 觀察實際 staleness 分布、調整 K/T

Failure 5：multi-region write 配 Strong

文件不允許 / 行為退化（時間敏感、查最新）— 必須改 Bounded / Session。這是 AP 取捨的硬約束、不是 config 問題；詳見 multi-region-write-conflict 的 AP 取捨段。

修：在 selection 階段就決定「要 active-active write 還是要 Strong」、不能事後補；要全球 linearizable 轉 Spanner / Aurora DSQL、要 active-active 接受 eventual / session / bounded。

Failure 6：Consistent prefix 誤用

把它當 Session 用、跨 session read 還是 stale、但比 Eventual 多一個順序保證；用錯地方等於浪費。常見誤判：「我要『順序對』、所以選 Consistent prefix」 — 但實際業務需求是「自己讀到自己寫的」、應該是 Session 而非 Consistent prefix。

修：

• Consistent prefix 適合 時序敏感但可跨 session stale 場景（新聞 feed、event log）
• 「自己讀到自己寫的」場景用 Session
• 跨 session 也要強一致用 Bounded / Strong

容量與觀測

• 必看 metric：NormalizedRUConsumption、TotalRequestUnits、ReplicationLatency（跨 region lag）
• Diagnostic Log：每個 request 的實際 consistency level、確認沒被預設 override
• 成本計算：Strong / Bounded read 算 2x RU；multi-region 開後寫入成本 × region 數；level 跟 region 數的 cost matrix 是規劃必算
• 回 9.6 容量規劃模型：consistency level 當「RU 倍數」進入容量公式
• Alert：
  • ReplicationLatency 突增（跨 region 同步異常）
  • Diagnostic log 偵測 Strong read 突增（成本失控）
  • 跨 service session token 缺失導致 stale read 比例上升

邊界與整合

• Sibling deep articles：partition-key-design（partition key 跟 consistency 共同決定真實一致性體驗）、ru-cost-model-sizing（RU 倍數量化）、multi-region-write-conflict（multi-region 下 consistency 的特殊行為、Strong + multi-region 互斥的 SSoT 主寫位置）、mongodb-api-vs-sql-api（MongoDB read concern → Cosmos DB consistency level 對應）
• 跟 Spanner vendor 對比：external consistency vs Cosmos DB Strong 不是同一個 thing
• 跟 DynamoDB vendor 對比：DynamoDB 只 strong / eventual 兩級、Cosmos DB 5 級提供細粒度
• 跟 1.x 章節：1.11 全球分散式 OLTP（Cosmos DB 5 level 跟 Spanner external consistency 並陳）
• Knowledge cards：consistency-level / linearizability / stale-read
• Anti-recommendation：別把 Cosmos DB Strong 跟 Spanner external consistency 等同視之；產品需要真正全球 linearizable transaction 時、Cosmos DB 不是替代品 — 轉 Spanner / Aurora DSQL

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 5 consistency levels backlog 的深度展開
• 9.C11 Minecraft Earth case — session consistency + 跨 collection 分流主案例
• 9.C21 ASOS case — 高 throughput + 較弱 level 補充
• multi-region-write-conflict — Strong + multi-region 互斥的 SSoT 主寫位置
• Consistency Level 卡片 / Linearizability 卡片 / Stale Read 卡片 — 概念基底
• 官方：Cosmos DB consistency levels / Consistency level overrides