本文是 Cloud Spanner overview 的 implementation-layer deep article。Overview 已說明 Spanner 在全球 OLTP 譜系的定位、本文聚焦 TrueTime API — Spanner 用來消滅 single coordinator bottleneck、換到 line-rate scaling 的核心機制。

商業邏輯先行：TrueTime 是手段、line-rate scaling 才是目的

TrueTime 的設計目的是消滅 single coordinator bottleneck、讓 OLTP 拿到 line-rate scaling — external consistency 只是這條路徑上拿到的副產品。讀者若把 TrueTime 當成「一個保證 external consistency 的精巧時間 trick」、會誤把工具當目標、後續所有 commit wait / Paxos / GPS 細節都解錯方向。

傳統 OLTP（PostgreSQL、MySQL、Cloud SQL）跨節點交易要靠一個 coordinator 決定全局順序、coordinator 本身就是 bottleneck。1x node = 1x throughput 的線性擴展在 single-primary 模型撞牆、想 scale 只能往應用層 sharding 走、付管理 shard key / 跨 shard query / resharding 的代價。Spanner 換掉這條路徑：TrueTime 把 wall-clock 變成跨 datacenter 可比較的 interval、Paxos 把 coordinator 變成「拓樸感知的多 leader」（每個 Range Sharding split 自己的 Paxos group 各自前進）、commit timestamp 用 TrueTime 對齊到 real-time 順序、不再需要一個全局 coordinator 串行所有 transaction。

9.C10 Cloud Spanner planetary scale case 揭露的線性擴展證據：「2 nodes → 45K reads/sec、4 nodes → 90K reads/sec」是 Spanner 設計目標的直接證據、不只是 marketing 數字。這條揭露 Spanner external consistency 不是「加強版 serializable isolation」、是「coordinator 換拓樸」的 paradigm shift。寫到這裡讀者該意識到一件事：選 Spanner 不是選一個更貴更強的 SQL、是選一條 把 coordinator 拆掉 的 scaling 路徑。

Dogfood 邊界（本文反覆強調）：9.C10 是 Google internal dogfood case、不是 customer-facing capacity 參考。「10 億 req/sec」是 Google 全使用者加總、不是單一 instance 配額；「2 nodes → 45K reads / 4 nodes → 90K reads」是 Google internal benchmark 揭露的線性擴展 模式、不是客戶 SLA 承諾。本文後續所有 9.C10 數字引用都會明示這條邊界、避免讀者誤把 dogfood 當配額。

Fact vs derive 分層警告：本段「coordinator bottleneck → TrueTime + Paxos」frame 是跨 Spanner 2012 OSDI 論文 + 公開文件（2024-2026）+ 9.C10 case 合成的工程 frame、不是 9.C10 case 直接展開實作層細節。9.C10 案例直接揭露的 fact 是線性擴展數字跟 dogfood 邊界；本文 derive 的 frame 是「為什麼傳統 OLTP coordinator 是 bottleneck」。引用時這條分層在每段引用具體數字時都會重申。

問題情境：跨 region OLTP 的順序漏洞

跨 region OLTP 想保證「全球用戶看到的交易順序跟 wall clock 一致」、但 NTP 同步誤差動輒 10-100ms、足夠讓 region A 已 commit 的計費事件被 region B 看到一個更新的 timestamp 卻是舊狀態。讀者徵兆通常從這幾個地方浮現：分散式系統團隊在 Cloud SQL / Aurora 多 region 上做 read replica、發現「跨 region read 順序顛倒」、audit log timestamp 不可靠、reconcile 對帳對不上、業務以為自己用了 transaction 就有「強一致」、實際只有 single-node 的 serializable isolation。

真實壓力場景：Google Ads 計費需要把每筆扣款事件放進可驗證的 外部 順序、不只是 transaction 內部 serializable。讀者若把這套需求帶回自家系統、會發現一條共同訊號 — 「兩個 transaction 都 commit 成功、用戶體感卻違反順序」這種事故、不是 isolation level 的問題、是 external consistency 的問題。

Case anchor：9.C10 Cloud Spanner planetary scale — Google Ads / Play 訂閱 / Search 計費跟 TrueTime 綁定。dogfood 邊界明示：9.C10 是 Google 內部 dogfood case、不是 customer-facing capacity 參考；引用其揭露的線性 scaling 模式時要分清「設計目標證據」vs「客戶可獲得配額」。

核心機制：TrueTime 的 API 跟硬體基礎

TrueTime 對外只有兩個 primitive — TT.now() 回傳一個 interval [earliest, latest]、不是單一時刻；TT.after(t) / TT.before(t) 判斷一個事件是否確定在 t 之後 / 之前。整個 external consistency 演算法都建立在「時間是一個 interval、不是一個點」這個 API 設計上。

硬體基礎：GPS + 原子鐘冗餘

每個 datacenter 部署 GPS 接收器 + 原子鐘（armageddon master、用來防 GPS 全網干擾）、time master 之間互相比對排除離群值、TrueTime daemon 從多個 master 拉時間並算 worst-case bound。GPS 給 absolute time reference、原子鐘給 short-term stability（GPS 短暫失聯時仍能用 drift bound 撐過去）。雙來源是為了把 ε 的失敗模式限制在「絕大多數時間 ε ≤ 7ms、極端事件下 ε spike 但不會無限制漂移」。

不確定性 ε（epsilon）

跨 datacenter 同步 + clock drift 估計、ε 目標維持在 1-7ms 區間。

Fact source 分層警告：1-7ms 是 Google 2012 OSDI 論文 + Spanner 公開文件（2024-2026）引用的範圍、9.C10 dogfood case 未直接揭露 production ε 分布。引用時這組數字明標「來自 Spanner vendor docs / 2012 論文、不是 9.C10 case 直接揭露」、避免讀者把兩種來源混為一談。

Commit wait 機制：external consistency 的核心

read-write transaction 要拿 commit timestamp s 時、Spanner 設 s = TT.now().latest、然後 等待 直到 TT.after(s) 才回 ACK。這段「等」就是 Commit Wait — Spanner 特有的物理延遲、由 TrueTime ε 主導、跟 Cross-Region Quorum 的網路 RTT 是兩個獨立的延遲來源、不能混算。

1T1 開始 commit            T1 確定可回 ACK
2       |                          |
3       v                          v
4TT.now().earliest .... s = TT.now().latest .... TT.after(s)
5       |--------- ε --------|
6                            |---------- commit wait ≈ ε ----------|
7       |---------- total commit wait ≈ 2ε（從拿 s 那刻開始） ---------|

commit wait ≈ 2ε 的數學保證了「下一個 transaction 拿到的 timestamp 一定 > s」、external consistency 的全序性質就由這個 wait 撐住。Fact source 分層：commit wait ≈ 2ε 的推導來自 Spanner 2012 OSDI 論文 + 官方文件、不是 9.C10 case 直接展開實作層數學。引用這條數學要附「來源 vendor docs / paper」、避免讀者誤以為這是 case 揭露。

跟通用 linearizability 卡片的差異

Linearizability 只要求「存在某個全序」、external consistency 進一步要求「全序跟 real-time 順序一致」。TrueTime 是把後者變可實作的關鍵 — 它把跨 datacenter 的「real-time 順序」變成可機械判定的 TT.after(s)、不需要全局 coordinator 來決定誰先誰後。對應的概念卡：external-consistency、linearizability、quorum。

操作流程：怎麼觀測 ε 跟調用 TrueTime

TrueTime 本身不對外暴露給 application 操作、ε / commit wait 由 Spanner 內部執行。團隊能做的是 觀測 ε 跟 選擇 不同強度的 read consistency。

觀測 ε

Cloud Monitoring metric spanner.googleapis.com/instance/clock_skew_ms 是 ε 的對外指標、判讀正常 < 7ms、異常 spike > 50ms 代表 time master 失聯或 GPS 干擾。把這條 metric 跟 commit_latencies p99 配成 evidence pair：ε spike 時 commit latency heatmap 應該整層平移、若 commit latency 動但 ε 沒動、不是 TrueTime 的問題、是 quorum / network 的問題。

跨 region instance 配置時的 TrueTime 影響

voting region 越分散、ε 上限越高、commit wait 越長 → write latency 直接受 ε 影響。multi-region instance config 在做 region layout 決策時要把「voting region 散布範圍」當 latency budget 的固定支出、不是配完才補觀測。

read-only transaction 的 staleness 選項

1strong              → 等 TrueTime 確認可讀最新、付完整 commit wait + quorum cost
2exact_staleness(t)  → 讀 t 秒前快照、避開 commit wait、適合 reporting / analytics
3bounded_staleness(t)→ 容忍 t 秒、可讀最近的本地 replica 副本、不跨 region quorum

stale / bounded staleness 走的是 Spanner 版的 Follower Read — 本地 replica serve 不參與 commit 的 read、避開跨 region quorum 把 read latency 降到 single-region 等級。

三者 trade-off 在 SDK 層顯式設定、不是 isolation level：

1// Spanner Go SDK 範例（time-sensitive、查最新文件確認 API）
2client.Single().
3    WithTimestampBound(spanner.MaxStaleness(10 * time.Second)).
4    Query(ctx, statement)

驗證點跟 rollback boundary

跑 cross-region write + cross-region read benchmark、量 p50 / p99 write latency、確認 ≈ 2ε + quorum RTT 的數量級。TrueTime 配置不由用戶調、commit wait 由 Spanner 自動執行；應用層 rollback boundary 在「改用 stale read / bounded staleness」而不是「關掉 TrueTime」 — TrueTime 是 Spanner 內部不可關的機制、不是 feature flag。

失敗模式：ε 暴衝跟誤用 strong read

ε 暴衝（time master 失聯）

GPS 干擾、datacenter time master 雙故障、ε 從 4ms 跳到 200ms → 所有 write 的 commit wait 暴增、p99 write latency 從 50ms 變 500ms。徵兆是 Cloud Monitoring commit_latencies heatmap 整層平移、clock_skew_ms 同步上升。根因不在 application、在 datacenter 物理層、修法是等 GCP 內部 time master 恢復、應用層只能臨時降到 bounded staleness 救 read path。

把 strong read 用在不需要的路徑

報表、analytics、user profile fetch 全用 strong read、每次 read 都付 TrueTime 對齊代價、p99 read 跟 write 同步退化。徵兆是 commit_latencies 沒動、但 api/request_latencies for ExecuteSql 整體上升。修法是把 read path 分類、reporting / analytics 改 bounded staleness、保留 strong read 給「讀後決策再寫」的 critical path。

在 client 側做「自己的 timestamp」

application 用 time.Now() 當業務 key、跨 region 寫入時 client clock skew 直接破壞順序 — Spanner 內部 external consistency 對、業務層卻錯。徵兆是對帳系統發現 timestamp 順序顛倒、但 Spanner audit log 都 OK。修法是業務層 timestamp 全改用 Spanner PENDING_COMMIT_TIMESTAMP sentinel、commit 時由 Spanner 填、不靠 client clock。

把 Spanner 當 single-region SQL 用、卻配 multi-region instance

每筆 write 都付跨洲 quorum + commit wait、cost 跟 latency 都浪費。徵兆是 instance config 是 multi-region 但實際 read 99% 來自單一 region、write 也是。修法是降到 regional instance、把跨 region 需求改用 read-only replica 或 export 到 BigQuery。

ε 沒監控

團隊直到事故才看 clock_skew metric、被動處理而非主動告警。建議 clock_skew_ms > 20ms warn、> 50ms page、跟 commit_latencies p99 偏離 baseline 2x 一起當 saturation discovery 訊號（回 9.4 Saturation Discovery）。

容量與觀測：TrueTime ε 是 latency budget 的固定支出

必看 metric：

1commit_latencies (p50 / p95 / p99)        → commit wait + quorum RTT 的總和
2api/request_count by method               → strong read vs stale read 的分布
3instance/cpu/utilization_by_priority      → high / low priority 分流
4clock_skew_ms                             → TrueTime ε 的對外指標

用 4.20 Observability Evidence Package 框架把 TrueTime ε 跟 commit latency 配成 evidence pair。Capacity 規劃路由回 9.6 容量規劃模型、把「ε × write rate」當 latency budget 的固定支出 — 寫越多筆、commit wait 累積成本越高、不是 free。

Alert 建議：

Line-rate scaling 驗證（呼應商業邏輯先行段）

擴 node 數時量「read throughput / node」是否維持線性 — 9.C10 揭露的 2 → 4 nodes = 45K → 90K reads/sec 是 Google internal dogfood 的線性模式、不是客戶 SLA 承諾。團隊在自己 instance 上要驗證的不是「能不能達到 90K reads」、是「擴 node 後 throughput / node 有沒有保持線性」。若曲線 sub-linear、檢查是否 hot split / hot range / Paxos group 不均、TrueTime 機制本身不解這層。

邊界與整合：何時不用 TrueTime（或不用 Spanner）

何時改用 stale read

reporting / analytics / dashboard 場景改用 bounded staleness 換 cost、不付 commit wait 的 latency tax。判準：若這個 read path 用 5 秒前的資料不會影響業務決策、改 stale read；若會、保留 strong read。

何時不該升 Spanner

單 region workload 不該為了 external consistency 升 Spanner、Cloud SQL + serializable isolation 已經夠。9.C10 dogfood 揭露的線性 scaling 是「跨 region + 大規模」場景的設計目標、單 region 用戶拿不到對應的 cost / latency benefit。詳見遷移判讀：Cloud SQL → Spanner Migration Playbook 的 no-go condition 段。

Sibling deep articles 路由

• consistency-models-comparison：為什麼 external consistency ≠ serializability ≠ linearizability、line-rate scaling 對照表、cross-region quorum 100-200ms 物理硬限
• schema-migration-interleaved-tables：schema change 也用 TrueTime 保證 version 邊界、parent-child storage layout
• migrate-from-cloud-sql-pg：cutover 階段需要把 application 對 timestamp 的假設審一遍（特別是 client 端 time.Now() 那條失敗模式）

跟 1.x 章節的互引

• 1.11 全球分散式 OLTP：Spanner 是 PC 系統的代表、Cosmos DB AP 系統當對照
• transaction boundary：external consistency 是 transaction boundary 的全球延伸

Anti-recommendation

讀者讀完本文應該能判斷：TrueTime 不是「保證強一致」的功能、是「換 scaling 路徑」的核心；若團隊只想要「強一致」、不需要「跨節點線性擴展」、PostgreSQL serializable + 應用層補上 client-side ordering 就夠、不必為 TrueTime 付 GCP lock-in 的 cost。

本文是 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 的判準很高。