本章從業務邊界切分開始、進入 isolation level 工程細節、再到 retry 策略、最後處理跨服務 / 跨 region 的 distributed transaction。讀完後讀者能回答：transaction 範圍該多大、isolation 該訂多嚴、deadlock 怎麼處理、跨服務一致性怎麼設計、什麼時候該換 Saga 模式。

邊界先於語法

交易邊界先從業務動作切分、再回到 SQL。建立訂單、扣庫存、寫付款狀態是一個動作；更新推薦分數、寫審計摘要、送通知事件屬於不同節奏、適合拆成後續流程。

當同一個動作內同時包含高延遲外部呼叫、交易範圍會直接放大鎖持有時間。穩定做法是把交易內責任收斂在「需要同時成功」的資料集合、讓外部呼叫或延伸副作用透過 queue / outbox 交給後續流程。

Isolation Level 五級深度

SQL 標準定義四個 isolation level、實務上 PostgreSQL / MySQL / Spanner 等實作有微妙差異。理解各級的具體行為、才能在 正確性 vs 性能 之間做取捨。

0. Read Uncommitted（dirty read 可能）：

• 可讀到別的 transaction 還沒 commit 的資料
• 多數 DB 不真的支援這級（會 fallback 到 Read Committed）
• 實務不要用

1. Read Committed（PostgreSQL / Oracle 預設）：

• 只讀到 commit 的資料
• 同一個 transaction 內、多次 SELECT 同一筆資料可能讀到不同值（non-repeatable read）
• 適合：read-heavy workload、不要求同 transaction 內 read consistency

2. Repeatable Read（MySQL InnoDB 預設）：

• 同 transaction 內 read 一致（snapshot at transaction start）
• 不防 phantom read（標準定義）、但 InnoDB 的 RR 加 gap lock 實際上防住了
• 適合：報表類 transaction、需要 snapshot 一致性

3. Serializable（最強）：

• 看起來像所有 transaction 序列執行
• 兩種實作：strict 2PL（lock-based、MySQL）vs SSI（snapshot isolation + 衝突檢測、PostgreSQL）
• 衝突時會 serialization failure、應用層必須 retry
• 適合：金融交易、ticketing inventory、需要絕對正確

4. External Consistency / Linearizable（Spanner、Aurora DSQL）：

• 比 Serializable 更強：跨 transaction 的順序跟 wall clock 一致
• 全球分散式系統的特殊取捨
• 詳見 1.11 全球分散式 OLTP 的 Spanner TrueTime 段
• 詳見 9.C10 Spanner case

選擇原則：

• 90% 業務用 Read Committed 夠
• 報表 / 對帳用 Repeatable Read
• 金融交易 / inventory 用 Serializable
• 全球強一致用 Spanner / Aurora DSQL 等 linearizable 系統

Isolation 跟 Retry 的關係

isolation level 的責任是定義交易彼此可見性。Read Committed 在高併發寫入下可維持一般業務一致性；Repeatable Read 與 Serializable 提供更強約束、同時提高鎖競爭與重試頻率。

併發交易的常見結果是 deadlock 或 serialization failure。這些結果代表資料庫在保護一致性、應用層需要把它視為可重試路徑：

• 重試次數有上限（通常 3-5 次）— 避免 retry storm
• 重試間隔有抖動（exponential backoff + jitter）— 避免同步衝突
• 重試前提是動作可重入（idempotent）— 不會放大副作用

對應 Exponential Backoff 跟 Idempotency 卡片。

Optimistic vs Pessimistic Locking

當多個 transaction 同時操作同一筆資料、有兩種防衝突策略：

Pessimistic locking（悲觀鎖）：

• SELECT ... FOR UPDATE、提前 lock 行
• 適合：衝突機率高、retry 成本高
• 缺點：lock 期間其他 transaction 等待、容易 deadlock

Optimistic locking（樂觀鎖）：

• 不 lock、用 version column 或 WHERE old_value = ?
• commit 時若 version 不對、整個 transaction 失敗、應用層 retry
• 適合：衝突機率低、性能優先
• 缺點：高衝突場景 retry 多、整體吞吐反而低

選擇邏輯：

• 衝突 < 5% → optimistic（更高吞吐）
• 衝突 > 30% → pessimistic（避免 retry waste）
• 中間區 → 量測再決定

對應 hot row contention 處理（1.1）— 高衝突 hot row 通常該換 KV / cache、不該硬擴 SQL。

服務情境：Checkout 多層邊界

電商 checkout 是典型的 transaction boundary 設計題、可拆成兩層邊界。

第一層：交易層（即時一致）：

• 建立訂單主表
• 寫入訂單項目
• 扣減可售庫存
• 寫入付款待確認狀態

第二層：延伸層（最終可達）：

• 寄訂單確認 email
• 同步 CRM 系統
• 觸發 analytics event
• 更新推薦模型

這種切法讓交易控制面跟非同步控制面各自穩定：

• 交易層關注 鎖、隔離與回退
• 非同步層關注 投遞、重試與補償

對應案例：

• 9.C4 DraftKings Aurora — 體育博彩 ledger、200 個獨立 cluster 處理 transaction、後續 settlement 跑非同步
• 9.C14 Standard Chartered — 跨市場銀行 transaction、各市場獨立、跨市場結算非同步

Distributed Transaction：2PC vs Saga

當業務動作跨越 多個服務 / 資料庫、傳統 ACID transaction 不夠用、需要 distributed transaction 模式。

Two-Phase Commit (2PC)：

• 階段 1：coordinator 詢問所有 participant「你能 commit 嗎？」
• 階段 2：所有都說 yes → coordinator 廣播 commit；任一說 no → 廣播 abort
• 優點：強一致、ACID 保證
• 缺點：coordinator failure 會 block 所有 participant、性能差、跨服務複雜
• 適合：少數高一致性需求的場景（金融交易、跨多 DB 一致性）

Saga Pattern：

• 把長 transaction 拆成多個 local transaction + compensating transaction
• 每個 step 成功 → 進下個；任一失敗 → 倒回去跑 compensation
• 例：訂單 step1 扣庫存、step2 收款、step3 送貨。step2 失敗 → 跑 step1 的 compensation（補庫存）
• 優點：高可用、性能好、容易擴展
• 缺點：不是強一致、中間狀態可見、compensation 必須設計
• 適合：multi-service 業務流程、可接受 eventual consistency

Choreography vs Orchestration：

• Choreography：每個 service 自己決定下一步（event-driven）
• Orchestration：中央 orchestrator 控制流程（state machine）
• 大規模傾向 orchestration（容易追蹤、debug）、小規模 choreography 足夠

對應案例：

• 9.C15 Tixcraft — 售票 + 付款分開：DynamoDB 接搶單（local transaction）、legacy server 跑付款（compensation 處理庫存回退）
• 9.C28 FanDuel — 投注 → 結算的 saga 流程

詳見 Outbox Pattern 卡片 跟 3.3 Outbox Pattern。

跨 Region Transaction：CAP 取捨

當 transaction 必須跨 region 同時成立、CAP 定理開始作用。

Single-region transaction（PostgreSQL / MySQL / Aurora）：

• ACID within region
• 跨 region 用 async replication、不是 transaction

Multi-region eventual consistency（DynamoDB Global Tables、Cosmos DB session/eventual）：

• 各 region 都能寫
• LWW 或 application-level conflict resolution
• 不是 ACID、是 BASE

Multi-region strong consistency（Spanner、Aurora DSQL、CockroachDB）：

• 跨 region linearizable transaction
• 代價是 latency（跨洲 100-200ms quorum）
• 對應 1.11 全球分散式 OLTP

決策邏輯：

• 業務不需要跨 region 強一致 → single-region OLTP + eventual replication
• 需要跨 region 強一致 + 接受 latency → Spanner / Aurora DSQL
• 需要跨 region 寫但接受最終一致 → Cosmos DB session / DynamoDB Global Tables

判讀訊號

常見誤區

交易保護的是一致性、不是吞吐量最大化。把過多步驟包進單一交易、會同時放大鎖競爭與回退成本。把交易切成可驗證的業務單位、能讓高併發下的可預期性更高。

重試保護的是暫時性失敗、不是所有失敗。沒有冪等保護的重試會放大副作用、特別是金流、庫存、配額這類正式狀態。

isolation level 不是「越強越好」。Serializable 比 Read Committed 慢數倍、且 retry rate 上升。只在 必要 場景用最強 isolation、其他場景用最低可接受 isolation。

distributed transaction 不是「跨服務就要 2PC」。多數 multi-service 業務用 Saga 更可靠、2PC 是少數場景的特殊工具。

案例對照

案例回寫

交易邊界可用 GitHub 2018 Oct21 MySQL Topology Incident 做回寫。先看事件中的主從切換與恢復順序、再回到本章判讀三件事：哪些變更必須同交易成功、哪些副作用應拆到 outbox、哪些錯誤屬於可重試而非立即回退。

這個案例主要支撐的是「提交與副作用切分」判讀、不直接支撐 schema naming 或 cache freshness；若問題落在資料命名或快取新鮮度、應回到 1.2 或 2.x。

若事件出現資料已寫入但外部流程落後、或重試後副作用重複、先收斂本章的邊界切分與重試前提、再同步更新 3.3 outbox pattern 與 3.4 consumer 設計。

跨模組路由

交易邊界設計會直接影響後續模組的可操作性。

1. 與 03 的交接：交易外副作用透過 outbox pattern 與 consumer 落地。
2. 與 1.7 的交接：付款狀態拆欄位、雙寫與回呼更新要進入 Schema Migration Rollout 證據 的驗證流程。
3. 與 1.10 / 1.11 的交接：KV 跟全球分散式 OLTP 的 transaction model 不同、選型時要回到本章邊界判讀。
4. 與 04 的交接：交易失敗需要對齊 Observability Evidence Package 的查詢與證據欄位。
5. 與 06 的交接：高風險交易變更納入 Release Gate 與 Migration Safety。
6. 與 08 的交接：交易層回退或 fail-forward 判斷記錄到 Incident Decision Log。

下一步路由

• 平行：1.1 高併發資料存取（connection pool / hot row）
• 下游：1.6 資料庫轉換實作 / 1.7 Schema Migration Rollout 證據 / 1.10 KV / Document DB 容量規劃 / 1.11 全球分散式 OLTP
• 跨模組：3.3 outbox pattern / 6.11 Migration Safety / 9.5 瓶頸定位流程
• 卡片：Isolation Level / Transaction Boundary / Idempotency / Outbox Pattern / Exponential Backoff
• Spanner 一致性深入：TrueTime API 深入 / Spanner 一致性模型對照
• CockroachDB retry / 隔離深入：CockroachDB transaction retry pattern / Aurora DSQL / Spanner / CockroachDB 決策樹
• Aurora 寫入語意深入：Aurora 儲存層架構（6 寫 / 4 讀 quorum 對 transaction 的影響）

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

對帳跑出一筆異常：用戶錢包餘額扣了 100 元、但對應訂單沒建立。追 log 發現 application 先 PutItem 扣餘額、再 PutItem 建訂單、兩步之間 process 被 OOM kill、第二步沒跑完。另一個系統反向情境：秒殺活動庫存剩 1、兩個請求同時讀到「剩 1」、各自 PutItem 扣成 0、實際賣出 2 件。兩個 production 痛點指向同一件事 — DynamoDB 預設的單筆寫入沒有跨 item 原子性、也沒有「讀到的值寫回時還沒被改」的保證。本文展開 DynamoDB 提供的三層寫保護：跨 item transaction、單 item conditional write、version-based optimistic locking。

寫一致性前提：先確認 workload 適配 DynamoDB：本篇假設 workload 已通過 DynamoDB 適配 4 軸（PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定）— 判讀軸詳見 single-table-design-pattern 開頭 4 軸前置判讀。寫一致性是 已選 DynamoDB 後的操作層議題；若 workload 需要頻繁跨多表多列複雜交易、那是 relational 的主場、應先回頭問 DynamoDB 是否選錯。

核心機制：三層寫保護

DynamoDB 的寫一致性由三種粒度不同的工具組成 — 單 item 寫、conditional write、跨 item transaction，三者解的問題與成本各異，不是單一 ACID 開關：

TransactWriteItems 的工程語意：

• 一次 transaction 最多含若干個 action（put / update / delete / condition check）— 上限屬 vendor 規格、實作時 cross-verify AWS doc 當前數字
• 全成功或全失敗：任一 action 的 condition 不成立、整個 transaction roll back、拋 TransactionCanceledException 帶 CancellationReasons
• 不跨 region、不跨 account：transaction 只在單一 region 單一 account 內成立、Global Tables 多 region 寫不享有跨 region transaction（對應 global-tables-conflict）
• 兩階段（prepare + commit）導致 2x capacity 消耗 — 這是 transaction 不能濫用的成本根源

Scope warning：「TransactWriteItems 100 action 上限」、「transaction 2x WCU」這些具體數字屬 AWS vendor 規格、會隨版本調整、實作時 cross-verify 官方 doc 當前值。本文不含對應 production case 揭露的 transaction 規模數字。

對應 knowledge card：idempotency、transaction boundary、isolation level。

Conditional Write：最便宜的一致性工具

跨 item transaction 之前、先看單 item conditional write 能不能解。多數「race condition」其實是單 item 問題、不需要 transaction 的 2x 成本。

ConditionExpression 在寫入前檢查條件、條件不成立則拒絕寫入並拋 ConditionalCheckFailedException：

1# 防重複建立：只有 item 不存在時才寫
2table.put_item(
3    Item={"PK": f"ORDER#{order_id}", "SK": "META", "status": "created"},
4    ConditionExpression="attribute_not_exists(PK)"
5)

1# 防超賣：只有庫存 > 0 時才扣
2table.update_item(
3    Key={"PK": f"SKU#{sku}", "SK": "STOCK"},
4    UpdateExpression="SET stock = stock - :one",
5    ConditionExpression="stock >= :one",
6    ExpressionAttributeValues={":one": 1}
7)

第二個例子是關鍵：update_item 帶 condition 是 原子的 read-modify-write。DynamoDB 在單 item 上保證「條件檢查 + 寫入」不會被其他寫入插隊。前述「兩個請求同時讀到剩 1」的超賣問題、用單 item conditional update 即可解、不需要 transaction。

Optimistic Locking：跨讀寫週期的保護

Conditional write 解單次寫的 race；當 application 需要「讀出來、業務邏輯運算、再寫回」、且運算期間不能被別人改、用 version-based optimistic locking。

機制是在 item 上維護一個 version attribute、寫回時用 condition 確認 version 沒被改過：

 1def update_with_optimistic_lock(pk, new_balance, expected_version):
 2    table.update_item(
 3        Key={"PK": pk, "SK": "WALLET"},
 4        UpdateExpression="SET balance = :b, version = version + :one",
 5        ConditionExpression="version = :expected",
 6        ExpressionAttributeValues={
 7            ":b": new_balance,
 8            ":one": 1,
 9            ":expected": expected_version,
10        },
11    )

讀出時拿到 version=5、運算後寫回時 condition 是 version = 5；若期間別人已寫成 version=6、condition 失敗、application 收到 ConditionalCheckFailedException、retry 整個讀-算-寫週期。

optimistic 的代價是衝突時要重試、不是阻塞等待。高衝突 workload（同一 item 大量並發寫）optimistic locking 會 retry 風暴、這時要回頭問資料模型 — 把熱點 item 拆開、或改用單 item atomic counter（ADD）避免 read-modify-write。

Scope warning：optimistic locking 是通用並發控制 pattern、DynamoDB 用 ConditionExpression 實作；本段機制描述屬 vendor 規格 + 通用工程知識、非 production case 揭露。

Idempotency：transaction 的重複提交保護

分散式系統的寫入會重試（network timeout、client retry）。同一筆 transaction 重送兩次、不能扣兩次款。DynamoDB transaction 提供 ClientRequestToken 做 dedup：

 1client.transact_write_items(
 2    ClientRequestToken=request_id,  # 同 token 在 dedup window 內視為同一次
 3    TransactItems=[
 4        {"Update": {  # 扣錢包
 5            "TableName": "wallet",
 6            "Key": {"PK": {"S": f"USER#{uid}"}},
 7            "UpdateExpression": "SET balance = balance - :amt",
 8            "ConditionExpression": "balance >= :amt",
 9            "ExpressionAttributeValues": {":amt": {"N": str(amount)}},
10        }},
11        {"Put": {  # 建訂單
12            "TableName": "orders",
13            "Item": {"PK": {"S": f"ORDER#{order_id}"}, "amount": {"N": str(amount)}},
14            "ConditionExpression": "attribute_not_exists(PK)",
15        }},
16    ],
17)

同一個 ClientRequestToken 在 dedup window 內重送、DynamoDB 視為同一次、不會重複執行。這解掉開場的「扣款成功但訂單沒建」問題：兩個 action 在同一 transaction、要嘛都成、要嘛都不成；client 重試帶同 token、不會重複扣款。

Scope warning：「ClientRequestToken dedup window 約 10 分鐘」屬 AWS vendor 規格、實作時 cross-verify 官方 doc；application 層仍應有自己的 idempotency key 設計、不依賴 vendor dedup window 當唯一防線（對應 idempotency 卡）。

操作流程

從一致性需求判讀到工具選擇的 6 步流程。

Step 1：分類寫入的一致性需求

每個寫入路徑標記它真正需要的保護：

• 單筆獨立寫、無前置條件 → 單 item put / update（最便宜）
• 單筆寫但要防覆蓋 / 防重複 / 防超賣 → 單 item conditional write
• 讀-算-寫週期、期間不能被改 → version optimistic locking
• 多筆 item 必須一起成功或失敗 → TransactWriteItems

Step 2：先用 conditional write 解單 item race

把「需要 transaction」當成最後選項。多數 race condition 是單 item 問題、conditional update 的 atomic read-modify-write 已足夠、成本 1x 而非 2x。

Step 3：跨 item 才上 transaction

只有「多筆 item 的修改必須綁在一起」才用 TransactWriteItems。例：扣錢包 + 建訂單 + 寫流水帳三筆綁定。寫進 transaction 的 item 數量越少越好、每多一個 item 多一份 2x 成本。

Step 4：加 idempotency token

所有會被 client 重試的 transaction 帶 ClientRequestToken；token 用業務層的唯一鍵（order_id / request_id）、不要用隨機值（隨機值每次重試都不同、dedup 失效）。

Step 5：處理失敗例外

 1from botocore.exceptions import ClientError
 2
 3try:
 4    client.transact_write_items(...)
 5except ClientError as e:
 6    code = e.response["Error"]["Code"]
 7    if code == "TransactionCanceledException":
 8        reasons = e.response["CancellationReasons"]  # 逐 action 失敗原因
 9        # 區分 ConditionalCheckFailed（業務拒絕、不重試）
10        # vs TransactionConflict / ThrottlingError（可重試）
11    elif code == "ConditionalCheckFailedException":
12        pass  # 單 item condition 失敗、業務層決定

關鍵：ConditionalCheckFailed 是 業務拒絕（庫存不足、訂單已存在）、不該不分原因一律重試；TransactionConflict / ThrottlingError 才是可重試的 transient error。混為一談會把「庫存真的不夠」當成 transient 一直重試。

Step 6：驗證點

1# 驗證 conditional write 真的擋住併發
2# 啟兩個並發 update 扣同一庫存、確認只有一個成功、另一個拋 ConditionalCheckFailed
3response = table.update_item(..., ReturnValues="UPDATED_NEW")
4print(response["Attributes"])  # 確認 version / stock 變化符合預期

Rollback boundary：transaction 本身全成全敗、無 partial state 需要 rollback；但 application 層若在 transaction 外還有副作用（送通知、呼叫外部 API）、那些不在 transaction 保護內、要另行設計補償。

失敗模式

production 常見的 5 個踩雷：

Case 1：用 transaction 取代本該單 item 的寫

team 把所有寫入都包進 TransactWriteItems「保險」、cost 翻倍、且 transaction 有 throughput 上限比單寫低。修法：transaction 只用於真正跨 item 綁定的場景；單 item 用 conditional write。

Case 2：optimistic lock 在高衝突 item 上 retry 風暴

熱點 item（如全站唯一的計數器）大量並發寫、version condition 不斷失敗、application retry 風暴、latency 爆炸。修法：高衝突計數改用 atomic ADD（單 item 原子累加、不需 read-modify-write）；或把計數 shard 成多個 item 分散寫入。

Case 3：idempotency token 用隨機值

這個 case 的失敗代價跟其他踩雷不同層級。Case 1（cost 翻倍）、Case 2（retry 風暴）、Case 5（跨 region 誤解）都可以在發現後調整設定或改資料模型補救；idempotency token 用隨機值導致的重複扣款是 財務不可逆 — 每次 client retry 產生新 token、dedup 完全失效、同一筆付款被執行多次、錢已經從用戶帳戶扣走、要靠對帳發現後人工退款，且退款流程本身又是另一條容易出錯的補償路徑。修法：token 綁業務唯一鍵（order_id / payment_id）、同一筆業務操作的所有重試共用同一 token；且不只依賴 DynamoDB 的 dedup window（有時效上限），application 層自己也維護 idempotency 記錄當第二道防線（對應 idempotency 卡）。涉及金流的寫入，這道防線要在上線前用「同一 token 重送 N 次只執行一次」的測試明確驗證。

Case 4：把 ConditionalCheckFailed 當 transient error 重試

庫存真的為 0、condition 永遠失敗、application 無限重試打爆 capacity。修法：例外分流 — 業務拒絕（ConditionalCheckFailed）回報給呼叫端、transient error（throttle / conflict）才 backoff retry。

Case 5：以為 transaction 跨 region 有效

Global Tables 多 region 部署、誤以為 TransactWriteItems 在跨 region 也原子。實際 transaction 只在單 region 成立、跨 region 是 last-writer-wins（對應 global-tables-conflict）。修法：跨 region 一致性需求不能靠 transaction、要重新設計資料 ownership（單一 region 為 write authority）。

Anti-recommendation：寫入無併發競爭、或業務本身可接受最終一致（各 message_id 獨立的訊息事件即屬此類）→ 不要為了求保險而加 transaction；transaction 的 2x 成本只在真正需要跨 item 原子性時才值得。

容量與觀測

CloudWatch metric：

• TransactionConflict：transaction 因併發衝突取消的次數、持續高代表熱點 item 競爭
• ConditionalCheckFailedRequests：condition 失敗次數、區分業務拒絕 vs 設計問題
• ThrottledRequests：transaction 因 capacity 不足被限流、transaction 的 2x 消耗更容易撞上限

判讀：

• TransactionConflict 持續上升 → 資料模型有熱點、考慮拆 item 或改 atomic counter
• ConditionalCheckFailed 突然飆高 → 可能是業務異常（大量重複請求 / 攻擊）、也可能是 application 邏輯把 version 算錯
• transaction 的 capacity 用量按 2x 計、容量規劃要把 transaction 比例算進去

Scope warning：本文未引用 production case 的 transaction metric 數字；上述 metric 名稱與判讀屬 vendor 規格 + 通用觀測工程。

接回 4.20 Observability Evidence Package、1.3 transaction 與一致性邊界。

邊界與整合

跟 relational transaction 的責任差異

DynamoDB transaction 跟 relational transaction 不是同一個東西。Relational transaction 支援任意複雜的多表多列交易、長交易、isolation level 調整；DynamoDB transaction 是「一次性提交一組有限 action、全成全敗、無互動式 transaction、無 SELECT FOR UPDATE」。當 application 需要長交易、複雜 join 內的一致性、或多步互動式 transaction、那是 relational 的場景、不該硬塞進 DynamoDB（回頭看 single-table 4 軸前置判讀）。

Sibling 與 cross-link

• consistency-model-optimization — 該篇主寫 讀 一致性（eventual vs strong read）、本篇主寫 寫 原子性、兩篇互補
• single-table-design-pattern — 跨 item transaction 常用於 single-table 內多 entity 綁定寫
• global-tables-conflict — transaction 不跨 region、多 region 寫衝突另有處理
• streams-lambda-event-driven — transaction 寫入會觸發 stream、下游 event 處理要 idempotent
• 替代路由：頻繁複雜交易需求 → 回 PostgreSQL / Aurora、relational transaction 是主場
• 對應 1.9 Reconciliation 與 Data Repair — 寫一致性失守後的對帳與修復

本文是 CockroachDB vendor overview 的 implementation-layer deep article。Overview 已界定 CockroachDB 的 PostgreSQL wire 相容定位、本文聚焦 serializable default 對 application transaction contract 的重塑。

Scope warning（最高、F4 Frame 2）：本篇整篇是跨 case 合成 frame、不是單一 case 揭露。3 個 CockroachDB direct case（9.C39 DoorDash / 9.C40 Netflix / 9.C41 Hard Rock Digital）對 application transaction retry contract 重塑的揭露 都偏弱 — DoorDash case 只寫 PostgreSQL wire protocol-level 相容、SQL 行為（serializable default / retry semantics / partial index）「仍要驗證」、沒直接寫 40001 serialization_failure / SAVEPOINT cockroach_restart / hot row contention / retry loop pattern。Netflix / Hard Rock case 完全沒寫 retry pattern。本章 retry pattern 議題從 Cockroach Labs 官方 SQL Layer docs + PG → CockroachDB 通用 contract 重塑視角合成、DoorDash 只作為 trigger context（撞牆訊號 + 觸發遷移）、不是 ground truth case study。讀者引用本章內容到實際系統前、應該 自己跑 application audit 而不是直接套合成的 pattern。

問題情境：從 PG READ COMMITTED 遷到 CockroachDB SERIALIZABLE 的 application 衝擊

團隊從 PostgreSQL（default READ COMMITTED）遷到 CockroachDB（default SERIALIZABLE）、上線後 application transaction retry 突然爆增、user-facing latency p99 高 5 倍、error rate 顯著上升。Driver 不會自動 retry — 應用層必須認得 40001 serialization_failure 並包 retry loop with exponential backoff。沒包就是直接拋例外給用戶。

讀者常問：

• 為什麼同樣的 transaction 在 CockroachDB 一直 retry、在 PostgreSQL 從來不會？
• 40001 serialization_failure error 怎麼處理、能不能直接 swallow？
• 我要把所有 application transaction 都改成 retry loop 包起來嗎？
• 能不能改 isolation level 回 READ COMMITTED、放棄 serializable 保證？

四題的回答都依賴一個前提：CockroachDB 的 application transaction contract 跟 PostgreSQL default 不一樣、必須重塑。

Scope warning explicit label：DoorDash case 沒揭露 retry pattern

DoorDash case 沒直接揭露 serializable retry contract / 40001 / SAVEPOINT pattern / hot row contention。case 只寫「PostgreSQL wire protocol 相容、實際 SQL 行為（serializable default、retry semantics、partial index）仍要驗證」（DoorDash 觀察段 / 策略段 3、F4.4）。

本章 retry pattern 議題是從 PG → CockroachDB 通用 contract 重塑視角合成、不是 DoorDash case 直接揭露。引用 DoorDash 時應該用：

• 正確口徑：「DoorDash 揭露 Aurora Postgres 1.636 M QPS 撞牆 → 引出 distributed SQL retry contract 需求、本章 retry pattern 議題是從 PostgreSQL → CockroachDB 通用 contract 重塑視角合成、不是 DoorDash case 直接揭露」
• 不要寫成：「DoorDash retry pattern」、「DoorDash 揭露 40001 處理」之類把合成包成 case fact 的語法

Case anchor（trigger context、不是 ground truth）

• 9.C39 DoorDash：提供「PG wire 相容、SQL 行為仍要 audit」的 case 警語（F4.4）、作為本章 為什麼 retry contract 要重塑 的觸發訊號。retry pattern 本體走 standard-driven（Cockroach Labs 官方 SQL Layer docs + Transaction Retry docs）

Sibling 對照 9.C4 DraftKings Aurora financial ledger 提供 PostgreSQL READ COMMITTED + Aurora 的另一條路徑 — 用 application-level sharding（200 個獨立 Aurora cluster）避開 retry、而不是處理 retry。Scope warning：DraftKings case 沒 寫 PostgreSQL READ COMMITTED retry pattern、case 是 Aurora 內 business sharding 路徑。本章引用 DraftKings 為「假想若把 DraftKings 遷 CockroachDB 會撞到 retry contract 重塑」合成對照、不是 case 直接揭露。

核心機制：serializable default 跟 PostgreSQL 的差異

來源分層：本段機制來源是 Cockroach Labs 官方 SQL Layer docs + Transaction Retry docs（standard-driven）、不是 從 case 抽取。3 個 direct case 都沒揭露這些機制細節。

Serializable 是 CockroachDB 的 default

CockroachDB 預設 SERIALIZABLE — 最強 isolation level、保證 transaction 結果等同某個 serial order（即所有 transaction 像逐個按順序執行）。對比：

Conflict detection：read / write set 衝突就 abort

CockroachDB 追蹤每個 transaction 的 read set 跟 write set。當兩個並行 transaction 的 read / write set 衝突、CockroachDB abort 後到的那個、發 Serialization Failure（40001 serialization_failure）。

對比 PostgreSQL serializable（SSI）：兩者都是「post-detect」、commit 時偵測 anomaly、不是 pre-lock。差別在 衝突偵測時機 跟 成本：

• PostgreSQL SSI：用 predicate lock 追蹤 query 條件、commit 時偵測
• CockroachDB：用 timestamp ordering + write intent、衝突 當下 就 abort

CockroachDB 的成本在「衝突立刻 abort 不等 commit」、好處是「retry window 較短、不會跑完整個 transaction 才發現衝突」。

Application 端 retry：driver 不自動處理

關鍵：CockroachDB driver 不自動 retry。application 收到 40001 serialization_failure 必須自己決定怎麼處理 — exponential backoff retry、circuit break、或拋給上層。

對比 PostgreSQL：PostgreSQL READ COMMITTED 幾乎不會丟 serialization failure（後 writer 等 lock 不 abort）、SERIALIZABLE 才會、但多數 application 沒走 SERIALIZABLE。CockroachDB 預設 就是 SERIALIZABLE、所以 retry loop 是 必要、不是 optional。

Savepoint pattern：官方推薦寫法

Cockroach Labs 官方推薦的 retry pattern 用 SAVEPOINT cockroach_restart：

 1BEGIN;
 2SAVEPOINT cockroach_restart;
 3
 4-- 做正常 transaction 工作
 5SELECT balance FROM accounts WHERE id = 1;
 6UPDATE accounts SET balance = balance - 100 WHERE id = 1;
 7UPDATE accounts SET balance = balance + 100 WHERE id = 2;
 8
 9RELEASE SAVEPOINT cockroach_restart;
10COMMIT;
11
12-- 如果中途 40001：
13-- ROLLBACK TO SAVEPOINT cockroach_restart;
14-- 重新跑 transaction body、再 RELEASE + COMMIT

cockroach_restart 是特殊保留 savepoint name — CockroachDB 認得這個名字、會把 ROLLBACK TO SAVEPOINT cockroach_restart 視為「重啟整個 transaction」而不是部分 rollback。

READ COMMITTED 是 v23.2+ 可選降級

CockroachDB v23.2+ 新增 READ COMMITTED isolation level — application 可選擇用 weaker isolation 換少 retry。但這是「降級」、失去 serializable 保證 — 對應的反例段在失敗模式段展開（金融 ledger 走 READ COMMITTED 可能讓 balance 變負）。

對應 isolation level 卡 跟 transaction boundary 卡。

DoorDash case 對接點（trigger context only）

DoorDash case 揭露 PG wire protocol-level 相容、明示 SQL 行為（serializable default / retry semantics / partial index）「仍要驗證」（F4.4）。本章機制段就是回答「audit 什麼」的具體展開 — 但 audit checklist 本體屬通用工程知識、case 沒 ground truth。

引用紀律：「DoorDash 揭露 PG wire 相容、SQL 行為仍要 audit、其中 serializable default 跟 retry semantics 是 application contract 重塑的核心議題」— 把 case 揭露的 fact 跟本章合成的 frame 分開講。

操作流程：retry loop 設計

Retry loop 偽碼

 1for attempt := 0; attempt < MAX_RETRIES; attempt++ {
 2    tx, err := db.Begin()
 3    if err != nil { return err }
 4
 5    _, err = tx.Exec("SAVEPOINT cockroach_restart")
 6    if err != nil { tx.Rollback(); return err }
 7
 8    // ... 跑 transaction body ...
 9
10    _, err = tx.Exec("RELEASE SAVEPOINT cockroach_restart")
11    if err == nil {
12        err = tx.Commit()
13        if err == nil { return nil } // 成功
14    }
15
16    if isSerializationFailure(err) { // SQLSTATE == "40001"
17        tx.Rollback()
18        backoff := time.Duration(math.Pow(2, float64(attempt))) * 10 * time.Millisecond
19        time.Sleep(backoff + jitter())
20        continue
21    }
22
23    tx.Rollback()
24    return err // 非 retry-able error
25}
26return ErrMaxRetriesExceeded

關鍵點：

• exponential backoff with jitter（避免 retry storm 同步）
• max retry 上限（避免無限 loop、要有 circuit breaker）
• 只 retry serialization failure、其他 error 直接拋
• transaction body 必須是 冪等 的（同樣 input 多次執行結果一致）

配置

1-- 改 transaction isolation level（v23.2+ 才支援 READ COMMITTED）
2SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
3
4-- 看當前 session 預設
5SHOW SESSION default_transaction_isolation;

驗證點

1-- 看 transaction retry 統計
2SELECT * FROM crdb_internal.txn_stats;
3
4-- 看哪些 query / table 衝突最多
5SELECT * FROM crdb_internal.cluster_contention_events ORDER BY count DESC LIMIT 10;

Idempotency 設計：transaction body 必須冪等

retry-safe transaction body 必須冪等 — 同樣 input 多次執行結果一致。這是 idempotency 在 distributed SQL retry contract 下的具體展開、不是 optional：

冪等性是 application 設計議題、不是 CockroachDB 配置可解的 — application contract 重塑的核心成本就在這。

Rollback 邊界

transaction 自身有 SAVEPOINT cockroach_restart 邊界、ROLLBACK TO SAVEPOINT 後可重試整個 transaction body。但：

• commit 後不可回滾 — 業務狀態還原只能新交易補償
• application 端如果在 transaction 外 cache state、retry 後 state 不一致（見失敗模式段）

失敗模式

Retry storm：contention 嚴重時 CPU 雪崩

當高頻寫入撞同一 row（例：全局 counter、熱門商品 inventory）、serializable 衝突率可能 100%、application 端 retry loop 不斷重跑、CPU 雪崩。

修法：

• Max retry 上限 + circuit breaker：超過就放棄、回 5xx 給 client、避免 retry storm 拖垮 cluster
• 改 schema 避開 hot row（partition by region、shard counter、用 sequence 代替全局 counter）
• 監控 crdb_internal.cluster_contention_events、針對 top-N table 改設計

非冪等 transaction 重試：double-count

最危險的 production bug：transaction body 不是冪等的、retry 後資料重複寫。ledger double-count、payment 重複扣款、log 重複記錄。

修法：

• transaction body 寫成 UPDATE balance SET balance = balance - X（相對運算）、不寫 UPDATE balance SET balance = Y（絕對賦值依賴 read 結果）
• INSERT 加 UNIQUE constraint + ON CONFLICT DO NOTHING
• 用 idempotency key（client 帶 UUID、server 端 dedupe）

Cross-statement state 假設

application 在 transaction 外 cache state（例：開 transaction 前 read 一個值、跑 transaction 期間用 cached 值）— retry 從 SAVEPOINT 重來時、cached state 不會重新讀、retry 後 state 不一致。

修法：

• 把 cached state 改成在 transaction 內 read
• retry loop 內 reset 所有 cached state
• 用 closure / scope 限制 cache 的生命週期到 transaction 內

Hot row contention

高頻 update 同一 row（例：全局計數器、熱門商品庫存、世界冠軍直播觀眾數）— serializable 衝突率接近 100%、無論 retry 多少次都繼續衝突。

修法（schema-level、不是 application-level）：

• 用 sequence 或 distributed counter（每節點本地 + 定期 aggregate）
• partition by hash key、把單一 row 拆成 N 個 sub-row
• 改 append-only + 定期 aggregate（事件流 + materialized view）

改 READ COMMITTED 後忘了驗證業務語意

v23.2+ 可改 READ COMMITTED、少 retry 但失去 serializable 保證。對金融 ledger：READ COMMITTED 可能讓 balance 變負（兩個並行 withdraw 都看到 balance=100、都扣 50、結果 balance=-50）。

修法：

• 金融 / 庫存 / 配額這類 strict consistency 場景必須留 SERIALIZABLE
• READ COMMITTED 只用在 容忍 stale read 的場景（搜尋結果 / 分析 dashboard）
• 改 isolation level 前 跑 application audit、確認業務語意能容忍

Long-running transaction：retry 機率隨時間線性上升

transaction read 開始時間早、commit 時 conflict window 大、retry 機率隨 transaction duration 線性上升。

修法：

• transaction scope 縮小 — 只包必要 read / write、不要把 RPC call / external API 放 transaction 內
• kill long-running query（SHOW SESSIONS + CANCEL QUERY）
• 把 batch update 拆成多個小 transaction、加 idempotency key

Distributed deadlock 跟 retry 互動

CockroachDB 用 distributed deadlock detection（每個 node 維護 wait-for graph、定期跨 node 交換）跟 PostgreSQL local lock 表的 deadlock detection 不同。一般情況下、被 detector 選為 victim 的 transaction 會直接 abort、application retry loop 應該收到 40001 後重跑。但在三種 corner case 下會跟 retry loop 形成雪崩 pattern：

• 多 transaction 同時撞同一組熱 row、deadlock detector 跨節點時間窗有 lag、多個 victim 同時 abort 後同時 retry、撞回同一個 deadlock window
• 跨節點的 distributed deadlock 偵測週期（預設 200ms+）放大 application retry latency、application 的 retry backoff 沒對齊偵測週期、形成「detect → abort → 快速 retry → 再 deadlock」迴圈
• Application 把 deadlock victim 當 40001 直接 retry、不分流出來看、就難以從 metric 區分「serialization conflict retry」跟「distributed deadlock retry」、調 schema / contention 的策略會用錯方向

修法（屬通用工程議題、case 未直接揭露）：

• Retry backoff 至少對齊 distributed deadlock 偵測週期、避免在偵測窗內快速 retry
• 加 jitter、不同 session 的 retry 不同步
• Application metric 分桶記錄 serialization_conflict_retry vs distributed_deadlock_retry、避免 contention 改善方向判錯
• Schema 設計階段避免「跨節點熱 row 環形依賴」（例：兩個服務交叉 update 對方的 counter row）

跨 case 合成 Scope warning：DraftKings 對照

DraftKings ledger 對照 — DraftKings case 沒寫 PostgreSQL READ COMMITTED retry pattern、case 內容是「Aurora 內 business sharding 路徑」、用 200 個獨立 cluster 解 Aurora single-primary 撞牆。本章把 DraftKings 拿來當「假想若遷 CockroachDB 需改 SERIALIZABLE + retry loop」的合成對照、不是 case 揭露的 fact。

實際 DraftKings 走 Aurora + application sharding 而非 CockroachDB、所以「DraftKings retry pattern」這個說法本身就是合成 — 應該寫成「DraftKings 走 Aurora sharding 避開 retry contract 重塑、若改走 CockroachDB 則需處理本章描述的 application 改寫」。

容量與觀測

必看 metric

• Transaction retry rate：per table、per session
• Serialization failure rate：絕對值 + ratio
• Transaction duration p99：long-running 是 retry 的根因之一
• Hot ranges by retry count：top contention 來源
• Application metric：retry count per request、retry-induced latency p99、circuit breaker trip count

容量公式

• 基底 QPS × (1 + avg retry count) = 實際 transaction load
• 例：1000 QPS、avg retry = 0.3 → 實際 cluster 處理 1300 transaction/s

retry rate 是 容量規劃必納入 的變數 — 沒算 retry 就會 underestimate 真實 load。

Tuning

• reduce transaction scope：transaction 越短、conflict window 越小
• kill long-running query：transaction 過長要主動截斷
• partition hot rows：schema-level 解 hot contention
• 改 isolation 到 READ COMMITTED（如果業務語意允許）

回路徑

• 9.5 瓶頸定位流程 判斷 retry-bound vs CPU-bound
• 9.6 容量規劃模型 retry rate × baseline QPS
• transaction boundary 卡
• isolation level 卡

邊界與整合

Sibling deep articles

• HLC + Raft consensus：為什麼 serializable 是 distributed SQL 的合理 default
• locality-aware schema：partition 降低 hot row contention
• survival goals：cross-region latency 加長 retry window

跟 PostgreSQL 對照

PostgreSQL READ COMMITTED 是 default、application 沒 retry loop 是 acceptable。遷 CockroachDB 必須 重塑 application transaction contract — 這是 migration 階段最容易 underestimate 的成本。

對應 PostgreSQL MVCC + SSI 機制細節、見 PostgreSQL MVCC + Lock Model。

Migration playbook

PG → CockroachDB 的 application audit 必看 transaction shape：

• 每個 transaction 的 read / write set 預估衝突率
• 是否冪等（retry-safe）
• transaction duration（long-running 是 retry 放大器）
• 業務語意能否容忍 READ COMMITTED（避開 retry 的 fallback）

1.x 章節互引

• 1.3 Transaction Boundary 上游 — distributed transaction 邊界
• isolation level 卡

何時不用本文

• 純 read-only workload、無 contention
• 已用 PostgreSQL serializable（application contract 相似、遷移衝擊小）
• 用 CockroachDB v23.2+ READ COMMITTED 且業務允許 stale read

相關連結

• CockroachDB vendor overview
• HLC + Raft consensus
• 9.C39 DoorDash（trigger context — PG wire 相容警語）
• 9.C4 DraftKings（合成對照 — Aurora sharding 路徑）
• PostgreSQL MVCC + Lock Model
• isolation level 卡 / transaction boundary 卡
• 官方：CockroachDB Transactions / Transaction Retry Error Reference / READ COMMITTED v23.2 announcement