本文 不 展開 vendor 機制細節（partition key 設計 / consistency level / RU sizing / connection management 等）— 那些屬 per-vendor deep article 的責任、本文在每個軸後 cross-link 過去。本文也 不 比較三家「誰比較強」— 三 vendor 在 workload-by-workload 適配光譜上各有位置、寫成優劣比較會誤導讀者把選型壓成單軸。

問題情境：讀者進來時的真實壓力

典型啟動壓力分兩類：

第一類、團隊評估 document / KV / multi-model NoSQL 三家、文件都說「scalable schema-less」、看不出實際取捨。讀者徵兆是「我的資料是 document-shaped 還是 KV-shaped？」「partition key 該怎麼選？」「Atlas 跟 Cosmos DB MongoDB API 不一樣的點在哪？」「Cosmos DB multi-model 是真用得到還是行銷話術？」「on-demand vs provisioned 怎麼選？」

第二類、既有 PostgreSQL / MySQL workload 撞 connection limit（surge 下 1K-5K pool 是隱性天花板、F1.7）、想換 KV 但不知道是否適合。讀者徵兆是「我已經有 Memcached、還要再加 MongoDB cache 層嗎？」「DynamoDB 適合當 OLTP 嗎？」「換 NoSQL 是不是解 connection 問題的銀彈？」

這兩類讀者進來時的 真實問題 不在 vendor 之間、在 workload 自己屬哪一型。Case anchor 覆蓋六個 unique 角度：

• 多型 document workload — 9.C38 Toyota Connected（車載 sensor schema 隨車型演進、20 個 Atlas DB blast radius 切分）
• Document 跨雲 hedging — 9.C37 Forbes（自管 → Atlas、6 個月遷移、跨雲彈性）
• 同 model 換 vendor 的 dogfood signal — 9.C30 Microsoft 365（MongoDB → Cosmos DB MongoDB API、保留 driver、wire compat 限制）
• KV-as-buffer 正向用例 — 9.C15 Tixcraft（DynamoDB 寫入緩衝、6750x 彈性、後端慢消費）
• PK 天然均勻典範 — 9.C5 Amazon Ads（90M reads/sec 年度峰值、KV pattern 純粹）
• Federated DB 真實系統 — 9.C36 Coinbase（MongoDB + DynamoDB + Memcached + mongobetween + freshness token）

Workload shape × access pattern × consistency 三軸前置判讀

進三家 vendor 對比前先回答：你的 workload 屬哪一型？三軸的組合決定 vendor 候選清單、軸不識別清楚直接比 vendor 是把選型壓成「品牌偏好」、不是工程決策。

軸 1 — 資料形狀：document / KV / 不清楚

資料形狀的核心判讀是 aggregate root 邊界是否明確 跟 schema 是否會隨產品演進新增欄位。document 適合的場景是資料天然多型、單筆記錄欄位差異大、應用層用 aggregate root 模式存取；KV 適合的場景是資料形狀固定、access pattern 數量少（< 5 種）、固定 lookup by key。

第三列的「暫緩 NoSQL」是反指標。NoSQL（特別是 DynamoDB single-table design）的核心假設是「access pattern 在設計時已知、後續變動有限」。資料模型還在探索、access pattern 半年內會大幅增減的場景、PostgreSQL + JSONB 給的彈性遠高於 NoSQL — JSONB 欄位可以演進、ad-hoc query 可以用 SQL 跑、未來釐清穩定 access pattern 後再選 NoSQL 不遲。

軸 2 — Access pattern 穩定度（KV 適用度前置判讀）

KV 適用度的核心判讀是 partition key 天然均勻度。partition key 不均勻會讓 vendor 廣告的「scale infinitely」變成「scale 到 hot partition 為止」、單一 logical key 流量超過該 partition 上限就 throttle 或 latency spike（F1.1）。

• 天然均勻 PK + 穩定 access pattern（meeting_id / player_id / message_id / user_id）→ DynamoDB / Cosmos DB Table API 適用、PK 不需 composite key 修補。Amazon Ads 用 ad_id 撐 90M reads/sec、Zoom 用 meeting_id、Capcom 用 player_id、PayPay 用 message_id、Disney+ 用 user_id — 五個 case 都揭露同一 frame：業務天然存在均勻 key 時 KV 是最自然的選擇。
• 天然不均勻 PK（event_id 一場演唱會集中 / date 時間序集中）→ 需 composite key 或 write sharding 修補。Tixcraft（9.C15）用 event_id + user_id_hash composite key 把單一熱門演唱會的 6750x spike 攤平到 partition 上 — 不是 DynamoDB 自身彈性、是 partition key 均勻分散的結果（F1.2）。
• Access pattern 變動頻繁（探索期、< 5 種 query 還會增加）→ 不適合 DynamoDB single-table design、回 RDB。Single-table 把 access pattern 編進 PK / SK 結構、增加新 query 等於改 schema、改 schema 等於重新 load 資料、成本不對。

KV 適用度判讀的延伸細節（hot partition 反模式 / composite key 設計 / adaptive capacity）見 DynamoDB partition key antipatterns。

軸 3 — Consistency 需求是否可接受 eventual

Consistency 需求的核心判讀是 跨 partition / 跨 region transaction 是否為產品契約。三家 vendor 都支援單 partition / 單 region 強一致、但 cross-partition / cross-region transaction 的機制跟限制差異大。

• 可接受 eventual / session consistency：DynamoDB（default eventually consistent reads、可選 strong）、Cosmos DB（5 個 consistency level、default session）、MongoDB（read concern 多級）— 三家都可以、選擇看其他軸。多數 KV / document workload 屬此類（social timeline、watchlist、message queue、analytics aggregation）。
• 需要強一致 cross-partition transaction：DynamoDB 跨 partition transaction 限制（單一 transaction 最多 100 個 action、跨 region 不支援）、MongoDB 4.0+ 支援 multi-document transaction 但 sharded cluster 仍有 limitation、Cosmos DB 跨 logical partition transaction 受限 — 都不如 SQL／distributed SQL 自然、應回 DB4 entry point 評估 Aurora DSQL / Spanner / CockroachDB。
• 跨 region active-active write：三家機制完全不同 — Cosmos DB multi-region write 跟 Strong consistency 是 互斥 設定（CAP 取捨硬約束、見 Cosmos DB multi-region write conflict SSoT 主寫位置）；DynamoDB Global Tables 走 LWW（last-writer-wins）conflict resolution；MongoDB Atlas 跨 region 需手動 conflict 處理。三家不在同一光譜、選擇前必看各 vendor outline 的機制段。

Migration path 三型（跨 case 合成 frame）

本段是 跨 case 合成 frame、不是單一 case 揭露 — 從 Coinbase（9.C36）/ Forbes（9.C37）/ Microsoft 365（9.C30）三 case 萃取的共通結構（F2.1）。

讀者進來時通常不是綠地、是 既有系統演進。三型遷移路徑的風險、ROI、適用條件完全不同、選錯路徑會推到錯的 vendor。

第一型：保留原 DB + 補周邊工具

不換 vendor、加 connection proxy（mongobetween / pgbouncer 類）、加 cache（Memcached + freshness token）、加 predictive scaling — 主資料層不動、應用層跟 ops 層補強。

• 代表 case：Coinbase（9.C36）保留 MongoDB Atlas、自建 mongobetween 把 60K connections/min 降到 ~2K（一個量級）、用 Memcached + freshness token 撐 1.5M reads/sec、用 ML predictive scaling 把擴容時間從 70 → 25 分鐘提前 60 分鐘
• 路徑成本：中（自建工具、需要工程資源 build & operate proxy / cache layer / ML model）
• 風險：低（主資料層不動、回滾代價小）
• ROI：保留主資料 schema + access pattern、解 driver / 部署模型 / cache 一致性瓶頸
• 適合：MongoDB（或主 DB）資料層撐得住、但應用層 connection storm / cache miss / 擴容慢卡瓶頸；團隊有工程能力 build 跟 maintain 周邊工具

延伸實作細節見 MongoDB connection management（per-vendor article、cross-link 待寫稿）。

第二型：同 DB 換託管

自管 → managed（Atlas / Cosmos DB / DocumentDB）、保留 schema 跟 access pattern、遷移期 6 個月量級。

• 代表 case：Forbes（9.C37）自管 MongoDB → MongoDB Atlas、保留 CMS schema、6 個月遷移、揭露「TCO 改善 25%」
• 路徑成本：中（dual-write + shadow read 驗證、driver 行為差異、operation runbook 重寫）
• 風險：中（dual-write 期間雙寫一致性、cutover 時點選擇）
• ROI：operation transfer（DBA bandwidth 釋放給 schema design / query tuning）+ TCO 改善
• 適合：自管 ops burden 大（DBA bandwidth 被 backup / patching / replica lag 吃光）、不想換 model

Scope warning（Forbes 25% TCO）：「25% TCO 改善」是 Forbes 特定流量規模（120M MAU、70+ Atlas region）下的數字、不普適。引用要帶條件 — 不要寫成「Atlas 比自管便宜 25%」這種 vendor-neutral 結論。實際省多少要看自管當下的 license / hardware / ops 工時分配、跟 Atlas 在你流量規模下的 pricing tier。

第三型：換 vendor 保留 model

MongoDB → Cosmos DB MongoDB API、或 MongoDB → DocumentDB — wire protocol + driver 不變、底層架構整個換、ops 模型整個換。

• 代表 case：Microsoft 365（9.C30）MongoDB → Cosmos DB MongoDB API、保留 MongoDB driver
• 路徑成本：高（dual-write per query pattern 驗證、wire compat ≠ 100% 行為相同、aggregation pipeline 跟 transaction 行為要逐項驗證）
• 風險：高（每個 query pattern 都可能踩到不相容 edge case、cutover 點選擇難）
• ROI：跨 vendor 換（Azure 生態 / multi-model API / global distribution）+ 保留應用層 driver code

Scope warning（Microsoft 365 dogfood）：Microsoft 365 是 Microsoft 自家 dogfood、case 沒揭露具體 throughput / latency / cost 數字（F2.17）。dogfood 是 高權重 selection signal（雲商賭自家旗艦產品）、但 不是 production benchmark（沒公開數字可比對）。引用要明示「dogfood signal」而非「production proof」。

Scope warning（100% wire compat）：Cosmos DB MongoDB API 廣告「100% wire compatibility」是 vendor 行銷話術、實際是「在某些 query pattern 下相容」（F2.9）。遷移時必須 dual-write per query pattern 驗證 — 不是看 vendor 文件 spec list、是用 production query corpus 跑一遍實測行為。Phase 0 audit checklist 應列出 unsupported aggregation stage、transaction edge case、index behavior 差異、change stream 跟 Change Feed 對應關係。

延伸 Cosmos DB MongoDB API vs SQL API 選型見 Cosmos DB MongoDB API vs SQL API。

第四型不在 DB3 範圍：paradigm shift 換引擎

KV → SQL 或 SQL → distributed SQL 屬 paradigm shift、應進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree。本文範圍是 DB3 三家內部選型、不展開 paradigm shift。

從 RDB 撞牆來的快速路徑

讀者若從 PostgreSQL / Aurora connection limit 撞牆過來、想評估 KV 替代、依撞牆訊號直接 route 到對應 article、不必先跑完三軸前置判讀：

• 撞 connection limit（surge 下 pool 1K-5K 隱性天花板、long-lived TCP 占滿）→ HTTP API 模型（no long-lived connection）的 KV 直接接寫入緩衝、進 dynamodb/single-table-design-pattern 的「durable queue / write buffer」段（Tixcraft 9.C15 路徑：DynamoDB 接訂單、傳統 server 慢消費）、或評估 Cosmos DB Table API
• 撞單 primary 寫入上限（單 leader 寫吞吐天花板、read replica 無法分擔寫）→ multi-primary distributed SQL 路徑、進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree 的 Path A（DoorDash 1.636 M QPS 單主寫入撞牆）
• 撞單一 DB 撐不下 + 多 workload 形狀並存（read-heavy / write-heavy / analytics 混在一個 DB）→ federated DB 模式、看 9.C36 Coinbase（MongoDB + DynamoDB + Memcached + mongobetween）+ 9.C29 Lemino（PostgreSQL → DynamoDB 揭露 RDB connection limit 隱性 bottleneck）

進 dynamodb/single-table-design-pattern 前先確認軸 1 / 軸 2 的 access pattern 穩定度跟 PK 天然均勻度 — connection limit 訊號 必要但不充分、KV 適用度 4 軸還是要走完、避免「為了解 connection 把不穩定 access pattern 硬塞 single-table」反模式。

Federated DB + system role 視角（跨 case 合成 frame）

本段也是 跨 case 合成 frame（F2.18 + F1.6）— 三個 rich case（Coinbase / Toyota / Forbes）都揭露 production 系統是 DB + 周邊工具 組合、不是單一 DB monolithic 撐起來。

讀者常誤以為「全用 X」是正解 — 全用 MongoDB、或全遷 DynamoDB、或全換 Cosmos DB。真實 production case 揭露兩個更前置的事實：(a) production 系統是 federated（多 DB 按 workload 分流）、不是 monolithic；(b) 每個 vendor 在系統中扮演 特定角色（control plane vs data plane vs cache）、不是 all-purpose store。

Federated DB by workload

Coinbase（9.C36）production 配置：MongoDB Atlas（document 主資料、identity service）+ DynamoDB（部分固定 KV workload）+ Memcached（read cache）+ mongobetween（connection proxy）+ Kinesis（event stream）。不是「全用 MongoDB」也不是「全遷 DynamoDB」、是按 workload shape 分流。

Toyota Connected（9.C38）：MongoDB Atlas 20 個 DB（microservice 拆 blast radius）+ Lambda + Kinesis + Redis + Kubernetes。20 個 DB 不是吞吐撐不住（18B txn/月 ≈ 7K txn/sec、單一 cluster 撐得下）、是 microservice ownership + blast radius 切分（F2.6）。

Forbes（9.C37）：MongoDB Atlas + 中介 abstraction layer + 50+ microservice。abstraction layer 隔離 schema 變動、避免 50 個服務都依賴 DB schema 細節（F2.3）。

三 case 揭露的共同 frame 是：寫 production 系統時假設「DB 一個服務搞定」、忽略 cache / queue / proxy / abstraction layer 跨層責任、會撞 connection limit / cache miss / cross-region replication 等隱性瓶頸。

System role：control plane vs data plane

DynamoDB 在 surge 場景能撐 nearly infinitely 不是 DynamoDB 自己神奇、是 系統架構解耦 的結果（F1.6）：

• Control plane（metadata、state、user record）：DynamoDB / MongoDB / Cosmos DB 適合 — 流量是 small payload + high QPS pattern
• Data plane（影音、大型 BLOB、media stream）：CDN / S3 / object storage、不在 DB3 範圍 — 流量是 large payload + bandwidth-bound
• Cache layer：Redis / Memcached / DAX（DynamoDB 補位）— 跟主 DB 形成跨層架構、處理讀峰值 + read-your-own-write 一致性

三個 case 揭露同一 frame：Zoom 視訊 metadata 走 DynamoDB、影音走 WebRTC / edge servers；Disney+ watchlist 走 DynamoDB、影片串流走 CDN + S3；Capcom game state 走 DynamoDB + DAX、game server 走 EKS。把影音串流塞 DynamoDB 是違反 control plane vs data plane 分離、容量規劃會錯（每筆 1KB 的 KV vs 每筆 100MB 的 media chunk 是不同 workload）。

三 vendor 對比 10 軸

下表是三 vendor 在 selection 階段的 10 軸對比。每個軸後續都有 per-vendor deep article 展開機制、本文不重複展開。

軸的延伸子段

部署 topology / 跨雲 hedging：三家 topology 是 vendor lock-in 跟 跨雲彈性 的硬取捨。Forbes 選 Atlas 不是當下省錢（自管 MongoDB 也可以、TCO 改善是副作用）、是 未來雲商策略尚未底定 的 hedging — Atlas 提供 AWS / GCP / Azure 三家部署、未來換雲不用換 DB（F2.10）。對照 DynamoDB / Cosmos DB / Spanner / Aurora 都是單雲鎖定 — 選了就跟著該雲商生態走。團隊雲商策略已底定（深度用 AWS / Azure / GCP 其一）時、單雲 vendor 通常較划算（更好的 IAM 整合、更深的 ops 工具、單一 support 通道）。跨雲價值真正成立是 策略不確定 或 合規要求多雲 場景。

Capacity 抽象：三家 capacity 抽象的 思維遷移成本 可能高過 vendor 廣告的價差（F2.12）。MongoDB 用 CPU + IOPS + working set RAM 三軸思維、跟自管 PostgreSQL / MySQL 類似、團隊轉換成本低。DynamoDB 用 WCU/RCU 抽象、要學「估每個操作消耗多少 unit」、加上 on-demand / provisioned / adaptive capacity 三模式選擇。Cosmos DB 用 Request Unit（RU）抽象、1 RU ≈ 1 KB document 的 strong read 成本、寫 ~5 RU、複雜 query 數百 RU — 工程師要學會用 RU 思考、不是用 CPU 思考、團隊知識遷移成本可能高。容量規劃延伸見對應 vendor 的 sizing article。

Partition / shard key 可逆性：三家 不在同一光譜、是選 vendor 前必做的 access pattern audit 重點（F2.15）。MongoDB reshardCollection（4.4+）可改、但成本高、需要 cluster downtime 或長時間 background migration。DynamoDB partition key 技術上可改、實作上用 backfill（建新 table、新 PK、雙寫舊新、cutover）— ops 工作量大但可逆。Cosmos DB partition key 不可改、改 partition key 等於 export-recreate-import — 對 1TB+ 資料是大型 migration 工程。三家不可逆性遞增、選 Cosmos DB 前必須前期完整 access pattern audit、不能「先上 production 之後再調」。

Consistency model：三家機制設計哲學不同。MongoDB read concern 是 per-operation 選擇（同一 client connection 可以混用）；DynamoDB strong vs eventual 是 per-read 選項（write 端統一強一致）；Cosmos DB 5 個 level 是 account-level default + per-request override、且 Strong 跟 multi-region write 互斥（CAP 硬約束）。設計上 MongoDB 最 flexible、Cosmos DB 最 explicit、DynamoDB 介於中間。延伸機制細節見 Cosmos DB consistency levels engineering、Cosmos DB multi-region write conflict（SSoT 主寫位置）。

Multi-model 差異化：Cosmos DB 是 唯一單一服務支援 5 API 的雲商 DB（SQL / MongoDB / Cassandra / Gremlin / Table）— 對照 AWS 走多產品覆蓋（DynamoDB KV + DocumentDB MongoDB-compat + Neptune graph + Keyspaces Cassandra-compat）、GCP 走多產品覆蓋（Firestore + Spanner + Bigtable）。multi-model 的差異化價值是 減少多 DB 並存運維 — 一個產品團隊只養一個 service、一套 IAM、一套 backup / DR、一套 monitoring。但 是否真用上 multi-model 要看團隊實際 workload — 多數團隊只用 1-2 個 API、單一 model 的競品（DynamoDB / MongoDB）可能更專注（F2.16）。

失敗模式（cross-vendor 反模式）

下列七條是三 vendor 都會踩、跨 case 共通的反模式。Per-vendor 特定反模式（例如 DynamoDB on-demand 隱性 hot partition、MongoDB schema 三代並存）在 per-vendor deep article。

反模式 1：把 DynamoDB 當 OLTP

訊號：access pattern 還在探索期、5+ 種 query 還會增加、強一致 cross-partition transaction 是產品契約。應回 PostgreSQL / Aurora、不是繼續加碼 DynamoDB single-table design。

DynamoDB 的 正確 用法包含 control plane KV（Zoom / Disney+ / Capcom）跟 durable queue / write buffer（Tixcraft 9.C15 揭露的非 OLTP 正向用例、F1.3）— DynamoDB 接「訂單」寫入、不是即時生效、是讓 traditional server（金流 / 票庫）用自己能承受的速度消費。這層解耦讓「前端可以擴 130 倍、後端不用同步擴」。

反模式 2：把 MongoDB 當 KV

訊號：access pattern 固定、PK 天然均勻、不需要 aggregation pipeline、document 內部從不展開（只查 root 欄位）。

應改 DynamoDB / Cosmos DB Table API。MongoDB 在這場景的 overhead（document overhead / connection model / aggregation engine 未用上）不划算 — KV vendor 的單筆讀寫成本更低、scaling 模型更簡單。

反模式 3：把 Cosmos DB 當跨雲服務

訊號：團隊評估 multi-cloud DR / 跨雲 portability、看到 Cosmos DB 文件強調「global distribution」就以為支援跨雲。

Cosmos DB 是 Azure-only、global distribution 指 Azure 內跨 region。想跨雲應改 MongoDB Atlas。multi-model 差異化是 Azure 生態內 的價值（F2.16）— 一旦離開 Azure、Cosmos DB 的所有獨特優勢都不存在。

反模式 4：federated DB 假設「全用 X」

訊號：寫架構設計時假設「DB 一個服務搞定」、不規劃 cache / queue / proxy / abstraction layer。

Production 真實系統都是 federated（Coinbase / Toyota / Forbes 都是）。寫架構時假設一個 DB 搞定會撞 connection limit（surge 下 RDB 第一個爆點、F1.7）/ cache miss（單靠 DB 撐不住讀峰值）/ cross-region replication（跨 region 一致性處理錯）等隱性瓶頸。預先設計 federated topology + 跨層責任分配、不是事後補。

反模式 5：誤判 dogfood case 數字

訊號：引用 Microsoft 365 / Amazon Prime Day 等 dogfood case 時、把它當 production benchmark、抄具體數字當 sizing 依據。

Dogfood case 數字常 不公開 或 不適用 customer-facing（F2.17 + F1.10）— Amazon Prime Day 「90M reads/sec」是年度峰值最高一秒不是平均、Microsoft 365 直接沒給數字、Google Spanner「10 億 req/sec」是 Google 全使用者加總不是單客戶配額。寫架構時引用要明示 selection signal（雲商賭身家、值得當高權重 vendor 訊號）vs production benchmark（具體 sizing 數字）— 兩者不可混為一談。

反模式 6：partition key 一上 production 才發現不可逆

訊號：選 Cosmos DB / DynamoDB 時、partition key 設計沒做完整 access pattern audit、上 production 一段時間後發現 hot partition、想改 PK。

三家不在同一光譜（見前段對比表）— MongoDB shard key 4.4+ 可改但成本高、DynamoDB 可 backfill 改、Cosmos DB 不可改 必 export-recreate。選 Cosmos DB 前要前期完整 access pattern audit、列所有預期 query 跟對應 PK 訪問頻率、確認最熱 PK 流量在單一 partition 容量上限內（F2.15）。

反模式 7：wire compatibility 當 100% 行為相同

訊號：選 Cosmos DB MongoDB API 或 DocumentDB、看到「MongoDB compatible」就假設 MongoDB driver 跑得起來就是相容、跳過 query pattern 驗證。

Wire compat ≠ 行為 100% 相同（F2.9）。Cosmos DB MongoDB API 廣告「100% wire compatibility」是行銷話術、實際是「在某些 query pattern 下相容」— aggregation pipeline 某些 stage 不支援、transaction edge case 行為差異、index 行為差異都會踩到。遷移必須 dual-write per query pattern 驗證、不是看 vendor spec list。

不該選 DB3 的訊號（升 SQL / 升 distributed SQL 路徑）

下列四條訊號出現時、選擇應跳出 DB3 範圍。

• JOIN-heavy + 強 normalize workload：應留 PostgreSQL（包括 PostgreSQL + JSONB 混合方案）、不該塞 NoSQL 再 $lookup。aggregation pipeline 的 $lookup 性能遠不如 SQL JOIN、在 sharded cluster 還有限制。
• 強一致 cross-region transaction 是產品契約：應進 DB4 entry point 評估 distributed SQL（CockroachDB / Spanner / Aurora DSQL）。三家 NoSQL 的 cross-region transaction 都有 limitation、不該當主路徑。
• 大流量 + 跨業務 fleet 治理：Aurora 200 cluster 模式（9.C4 DraftKings 揭露的 business sharding fleet）可能更合適、進 Aurora fleet 治理。NoSQL 的 fleet 治理工具鏈（cluster lifecycle / cross-cluster query / unified IAM）通常不如 managed SQL 成熟。
• 資料模型還在探索 + access pattern 變動快：暫緩 NoSQL 選型、用 PostgreSQL + JSONB 過渡。JSONB 給 document-like flexibility、SQL 給 ad-hoc query power、未來釐清穩定 access pattern 後再選 NoSQL 不遲。

下一步路由（per-vendor outline 子組）

讀者識別 workload type（軸 1-3）+ migration path（三型）+ system role（federated / control plane）後、進對應 per-vendor 子組繼續深化。

MongoDB 子組

• 入門：schema design pattern（contract layer 三選一：DB 層 validator / app 層 abstraction / 混合）
• 容量：shard key selection（單 cluster vs 多 cluster blast radius、Toyota 20 DB 模式）
• Migration：migrate to Atlas（同 DB 換託管型）

DynamoDB 子組

• 入門：single-table design pattern（access pattern 設計 + 適用度前置判讀）
• 機制：consistency model optimization（strong vs eventually consistent 取捨）

Cosmos DB 子組

• 入門：MongoDB API vs SQL API（API model 選型、四層 framing）

跨層架構（federated DB / cache / proxy）

跨層架構的延伸內容見對應 per-vendor connection management / cache layer article（後續會寫）— 本文只在軸 2 / federated frame 點到、不展開機制。

進 DB4 evaluation

若需要強一致 cross-region SQL / paradigm shift（KV → distributed SQL 或 SQL → distributed SQL）、進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree。

Knowledge card 路由

本文涉及的 knowledge card：

• document-store — document model 的核心概念跟 aggregate root 邊界
• hot-partition — KV vendor 的 partition 容量上限機制
• database-sharding — shard key 跟 partition key 設計
• consistency-level — strong / eventual / session 三類取捨
• vendor-lock-in — 單雲 vs 跨雲的 hedging 取捨
• distributed-sql — 跳出 DB3 進 DB4 的概念入口

教學路線：Access pattern 與 partition capacity

DynamoDB 服務頁的教學目標是把 access pattern 轉成 partition key、sort key、GSI、capacity mode 與 global tables 的設計判斷。讀者讀完後要能從查詢路徑反推資料模型，並估算 hot partition、成本與 consistency trade-off。

定位：partition-based KV scale

DynamoDB 的核心設計是「partition 透明、capacity 抽象化」。不像 MongoDB 要主動 shard、不像 Cassandra 要管 ring topology、不像 PostgreSQL 要選 instance type — DynamoDB 把所有底層 scaling 隱藏在 RCU / WCU 抽象層後。

容量單位：

• 1 RCU（Read Capacity Unit）= 1 strongly consistent read of 4KB / sec、2 eventually consistent reads
• 1 WCU（Write Capacity Unit）= 1 write of 1KB / sec
• 每個 partition 上限：3000 RCU / 1000 WCU
• 總容量 = partition 數量 × 每 partition 上限（partition 數量透明、vendor 自動管理）

延遲特性：

• single-digit millisecond p99 latency（read / write）
• 同 region 跨 AZ replication 內建、預設 eventually consistent reads
• strongly consistent reads 依 region 內 quorum 成立，跨 region 讀寫要看 Global Tables 語意

詳見 1.10 KV / Document DB 容量規劃 跟 9.4 Saturation Discovery 的 partition 設計章節。

適用場景

按公開 case 提煉的典型適用場景：

1. KV / single-table design 為主的查詢：

• 用 partition key + sort key 設計、單筆 / 範圍查詢
• 查詢路徑固定，JOIN / ad-hoc query 需求低
• 對應案例：9.C5 Amazon Ads — 9000 萬 reads/sec + 500 萬 writes/sec、99.999% 可用

2. 可預測 sub-10ms p99 latency 需求：

• 遊戲後端（玩家狀態、戰績）
• 內容平台 metadata（watchlist、播放進度）
• 對應案例：9.C19 Capcom（billions of requests / single-digit ms）、9.C27 Disney+（每日數十億 actions）

3. 流量 spiky 或 surge 場景：

• on-demand capacity 自動吸收 burst
• 不需 connection pool（HTTP API、無 stateful connection）
• 對應案例：9.C18 Zoom（COVID 1000 萬 → 3 億 DAU）、9.C15 Tixcraft（IOPS 20 → 135K、售票搶購）、9.C29 Lemino（RDB connection limit → 改 DynamoDB）

4. 大規模通知 / 訊息系統：

• TTL 自動清理過期 records
• partition key 用 user_id / message_id 天然均勻
• 對應案例：9.C26 PayPay（行動支付每日 3 億訊息）

5. 5 個 9 可用性 B2B SaaS：

• multi-region Global Tables active-active
• 對應案例：9.C24 Genesys（99.999% 跨 15 region）

6. 高吞吐 budget 敏感：

• on-demand 適合突發、provisioned 適合 sustained
• 對應案例：9.C20 Zomato — TiDB over-provision 壓力轉成 DynamoDB on-demand pay-per-use，成本下降 50%

不適用場景

1. 複雜 ad-hoc query / JOIN：

• DynamoDB query 以 partition key + sort key 為主，JOIN-heavy workload 交給 SQL 系統
• PartiQL 提供 SQL-like 語法但底層還是 KV、複雜 query 會 scan 全表
• 替代：用 Aurora / PostgreSQL / Spanner

2. 強一致 multi-row transaction：

• DynamoDB Transaction 支援 25 個 item 的 ACID
• 超過 25 個 item 或跨 region 的 transaction 要改用 workflow / SQL / distributed SQL 設計
• 替代：Spanner / Aurora DSQL / CockroachDB

3. 跨雲需求：

• DynamoDB only on AWS、vendor lock-in
• 替代：Cosmos DB（Azure global NoSQL）、自管 ScyllaDB

4. 大物件 / 文件儲存：

• 單一 item 最大 400KB
• 大物件用 S3、metadata 用 DynamoDB

5. 預算極度敏感 + 流量穩定：

• 流量高度 predictable 的 sustained workload，自管 PostgreSQL / MySQL 可能更便宜
• DynamoDB 的 managed 跟 elastic 是有溢價的

跟其他 vendor 的取捨

vs MongoDB（自管或 Atlas）：

• DynamoDB：managed、partition 透明、application 主要管理 partition key，有 5 個 9 SLA
• MongoDB：彈性高、可自管、aggregation pipeline 強、跨雲可用
• 選 DynamoDB：AWS-only、想轉移 operation、partition 設計簡單可預測
• 選 MongoDB：跨雲、複雜 query、ad-hoc analysis

vs Aurora（同 AWS）：

• DynamoDB：KV、partition 擴展、無 connection pool 限制
• Aurora：SQL（PostgreSQL / MySQL）、有 transaction、ad-hoc query
• 詳見 1.10 KV / Document DB 容量規劃 跟 9.C29 Lemino case — connection limit 是 RDB vs DynamoDB 的關鍵差異

vs Redis（含 ElastiCache）作為 KV 替代：

• DynamoDB：持久化、單 item 持久查得到、有 TTL 但物件不會自動失蹤
• Redis：純記憶體、預設不持久（MemoryDB 例外）、快但易失
• 選 DynamoDB：data 是 source of truth，需要持久保存
• 選 Redis：data 是 cache、丟了能 recompute

vs Cosmos DB（cross-cloud）：

• DynamoDB：AWS-only、KV 為主、無 multi-model
• Cosmos DB：Azure-only、multi-model（SQL / Mongo / Cassandra / Gremlin / Table）、5 個 consistency levels
• 選 DynamoDB：AWS 生態、KV 純粹
• 選 Cosmos DB：Azure 生態、需要 multi-model、需要 multi-region active-active write

vs Cassandra / ScyllaDB（self-managed）：

• DynamoDB：managed、5 個 9 SLA、無 ops 負擔
• Cassandra / ScyllaDB：可自管、更深 tuning、跨雲可用
• 選 DynamoDB：團隊想把 DBA / SRE 操作責任交給 AWS
• 選 Cassandra / ScyllaDB：有 DBA、想 lock-in 風險低、需要極限 throughput tuning

vs PostgreSQL（SQL baseline）：

• 詳見 PostgreSQL vendor page 取捨段、跟 1.10 KV / Document DB 容量規劃 的 connection model 對比
• 摘要：DynamoDB 是 access pattern 固定 + 需要避免 connection-bound 的選項；ad-hoc query / 複雜 transaction 留 PostgreSQL

容量規劃要點

從 09 案例庫提煉的 DynamoDB 容量規劃實踐：

1. partition key 設計是命脈：

• partition key 不均 → hot partition → 名義容量達不到
• composite key（event_id + user_id_hash）強制分散
• 對應 9.C5 Amazon Ads 9000 萬 RPS 靠 partition 均勻、9.C15 Tixcraft 用 composite key 分散售票流量
• 詳見 Hot Partition 卡片

2. on-demand vs provisioned 選型：

• 流量 peak/avg > 5x → on-demand
• sustained predictable → provisioned + auto-scaling
• 知名大事件（Black Friday）→ provisioned baseline + scheduled scale-up
• 對應 9.C20 Zomato — on-demand 解放 over-provisioning

3. Global Tables（multi-region active-active）：

• 每個 region 都能寫、conflict resolution 用 LWW
• 容量在每個 region 獨立配置，全球總和要按 region 分別估算
• 對應 9.C24 Genesys — 15 region 達 5 個 9 可用

4. DAX（DynamoDB Accelerator）：

• DynamoDB 前置 in-memory cache
• 從 single-digit ms 降到 microsecond
• 適合超高 read 重複的 workload（同樣 key 大量讀）
• 對應 9.C29 Lemino 用 DAX 加速

5. Streams + Lambda：

• DynamoDB 寫入 → Stream event → Lambda 處理
• 適合 CDC、event-driven 工作流
• 對應 9.C15 Tixcraft 用 Stream 把 DynamoDB 當 durable queue 給 legacy server 消費

Anti-recommendation 與升級路由

DynamoDB 的 managed elasticity 會讓團隊忽略 access pattern 的前置成本。這一段先說何時維持單純 table / index，再說何時升級到 Global Tables、DAX、Streams、或改回 SQL / document DB。

DynamoDB 的簡單路徑是先把每個 query path 寫成契約。table、partition key、sort key、GSI 與 TTL 都應從 access pattern 反推；如果需求仍在探索期，PostgreSQL 或 MongoDB 可能提供更低的變更成本。

Global Tables 的升級路徑要先處理 conflict 與讀寫語意。它提供 multi-region availability，但 LWW conflict resolution、region-local capacity 與跨 region reconciliation 仍要由 application contract 承擔。

Deep article（已完成）

本 vendor 現有 deep article 覆蓋 DynamoDB 從 access pattern 反推到寫一致性、讀加速、事件驅動與資料生命週期的核心 production 議題：

Migration playbook：從 RDS / MongoDB 遷移到 DynamoDB（Type E paradigm shift、access-pattern-first 重建模 + 混合架構 + Zomato cost crossover）。

跨 vendor entry：先看 DB3 vendor selection（MongoDB / DynamoDB / Cosmos DB 三方選型 + workload shape 前置判讀），再進本 vendor 的 deep article。

後續擴充（仍待補）

• DynamoDB Streams 進階 lab：Kinesis Data Streams for DynamoDB 多消費者 fan-out 與長 retention 重播（Lambda vs Kinesis 比較層已在 streams-lambda-event-driven 覆蓋、此處指可操作的深度 hands-on lab）
• Export to S3 / point-in-time export 做離線分析
• DynamoDB → SQL / search / analytics split（遷出方向 playbook）
• Backup / PITR restore drill（hands-on lab）

案例對照

DynamoDB case 的讀法是先分類 access pattern，再看容量模式。Amazon Ads / Capcom / Disney+ 說明高吞吐 KV，Zoom / Tixcraft / Lemino 說明 surge 與 connection-free scaling，Zomato 則說明 on-demand cost model 如何改變 over-provision 壓力。

反向 sibling 路由

DynamoDB 的反向 sibling 路由用來把 RDBMS 退場條件寫清楚。若讀者從 PostgreSQL / MySQL 的 connection bottleneck 過來，先讀 Lemino case 與 1.10 KV / Document DB 容量規劃；若需求仍需要 ad hoc SQL、join 與 transaction report，回 Aurora vendor 或 PostgreSQL vendor；若需求是 global document model 與 Azure 生態，再對照 Cosmos DB vendor。

這條路由的判準是 access pattern 是否穩定到可以先設計 key。DynamoDB 擅長固定 lookup、寫入尖峰、connection-free scaling 與 TTL 類生命週期；資料探索、報表 join 與多條件查詢仍應留在 SQL / search / analytics service。

常見陷阱

從公開 incident 跟 case 提煉：

• partition key 集中：event_id 一個演唱會、bot user 大量同 user_id 寫入 → 用 composite key 或 write sharding
• 單一 partition 達 3000 RCU / 1000 WCU 上限：throttling event 出現、即使整體 capacity 還沒滿
• Scan 全表：scan 會吃光 capacity，正式讀取路徑應回到 query / index design
• DAX 跟 DynamoDB 直連混用：寫入直連 DynamoDB、讀經過 DAX → cache 一致性問題
• Global Tables conflict：跨 region 同 key 同時被寫、LWW 可能丟失寫入、要設計 idempotency

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：Aurora vendor page（SQL 對比）
• 上游：1.10 KV / Document DB 容量規劃
• 下游：1.12 大規模 DB 遷移實戰（從 RDBMS 遷 DynamoDB 案例）
• 跨模組：9.4 Saturation Discovery、9.6 容量規劃模型
• Last reviewed：2026-05-22（capacity mode / Global Tables / best practices 屬時間敏感 claim）
• 官方：Amazon DynamoDB Customers、DynamoDB 設計 best practices

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

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

team 用 RDBMS 設計思維建多個 DynamoDB table（user / order / order_item）跑了一季、第二季開始撞「每個 query 要打 2-3 個 table、application 端拼接邏輯爆炸、latency 跟 cost 線性上升」。最直覺的補救是再加 GSI、結果 GSI 數量超過 5 個還是抓不到 access pattern。這時 team 通常開始問「DynamoDB 怎麼 join」— 那是 誤問。DynamoDB 不做 join，要嘛把相關 entity 放同 PK 用 SK 前綴區分（single-table design），要嘛這個 workload 根本不該用 DynamoDB。本文先回答後者（DynamoDB 適用度前置判讀），再展開前者（single-table 設計流程）。

DynamoDB 適用度前置判讀（4 軸）

進到 single-table 設計細節之前要先判讀 workload 是否在 DynamoDB 適用區。下面 4 個維度同時成立、single-table 才有意義；任一條不成立、改回 SQL / 多 vendor 組合可能更便宜。9 個 production case（Zoom / Disney+ / Capcom / PayPay / Tixcraft / Lemino / Amazon Ads / Genesys / Zomato）跨 case 重複揭露這 4 軸是適用度的真實邊界。

軸 1：Partition key 是否天然均勻

DynamoDB 容量 = 每 partition 上限 × partition 數量、最熱 partition saturation 就是 workload 的天花板。meeting_id（Zoom）/ player_id（Capcom）/ message_id（PayPay）/ user_id（Disney+）這類 ID 天然散布、不會集中在少數 partition；反之 event_id（Tixcraft 售票）/ date（時間序）/ status（少數枚舉值）這類 PK 天然不均勻、要 Composite Partition Key 修補才能 single-table。修補成本見 partition-key-antipatterns。

9.C18 Zoom、9.C19 Capcom、9.C26 PayPay、9.C27 Disney+ 4 個 case 都揭露 partition key 天然均勻是 DynamoDB 「能撐」的前提之一。

軸 2：Workload 是 control plane 還是 data plane

DynamoDB 適合存 metadata / state，實際大流量（影音串流 / 大型 BLOB / 全文搜尋）走 CDN / WebRTC / object store。9.C18 Zoom 把媒體串流放 P2P + edge servers、DynamoDB 只承擔會議 metadata；9.C27 Disney+ 把 content 放 S3 + CDN、DynamoDB 只承擔 watchlist + 播放進度；9.C19 Capcom 把即時遊戲邏輯放 EKS、DynamoDB 處理持久狀態。讀者該問的不是「DynamoDB 能撐多大流量」、是「我的系統哪一層該放 DynamoDB」。

如果 workload 是 data plane（單筆 payload 上 MB、要做全文搜尋、要存 BLOB），用 DynamoDB 是反模式 — single item 上限 400KB 直接擋掉 BLOB 場景。

軸 3：Consistency 需求是否可接受 eventual

DynamoDB 預設 eventually consistent read、strong read 也只在同 region quorum 內成立。最終一致性可接受的 workload 才適合；strong consistency 必要（跨 entity 原子寫入 / 跨 region 強一致 / 全局單調遞增 ID）必須走 SQL / NewSQL。本軸屬通用工程判讀、case 沒有揭露具體 staleness 閾值；判讀工具是 consistency-model-optimization 的 per-call site review。

軸 4：Access pattern 是否穩定

access pattern 數量穩定且窮舉可列（典型 10-30 個）single-table 才能精準設計 PK/SK 跟 GSI；查詢仍在探索期、pattern 頻繁變動，SQL 多 table 較容易演化、改 query 不用改 schema。本軸也屬通用工程判讀、case 沒明示 access pattern 數量閾值，但 9 個 case 寫進 production 的 access pattern 多半是 業務契約已凍結 的場景（會議 metadata、watchlist、玩家戰績、訊息推送）。

任一軸不成立、回 PostgreSQL vendor 或考慮多 vendor 組合。4 軸都成立、再進 single-table 設計。

核心概念：access pattern 先於 schema

Single-table design 的 first-class concept 是 access pattern 先於 schema：先列 15-30 個 query 才開始設 key、不是先設 schema 再想怎麼 query。

DynamoDB 的 key 結構：

• PK（partition key）：決定資料散布到哪個 partition；同 PK 的 item 物理共置（item collection）
• SK（sort key）：決定同 partition 內排序與範圍查詢；composite SK 用 # 分隔層級（如 ORDER#2026-05-27#001）
• 同 PK 不同 SK 前綴：把相關 entity 物理共置、用一次 Query 拿回多個 entity；對應 RDB 的 JOIN

實際範例（Disney+ 9.C27 揭露的 access pattern）：

1PK             SK                          Entity
2USER#u123      PROFILE                     用戶資料
3USER#u123      WATCHLIST#m456              觀看清單項目
4USER#u123      PROGRESS#device-iPad#m456   播放進度
5USER#u123      PROGRESS#device-TV#m456     播放進度（跨裝置）

一次 Query PK=USER#u123 拿回該 user 的所有資料、不需要 join。SK 前綴 PROFILE / WATCHLIST# / PROGRESS# 區分 entity type、range query 還能限定「只取 watchlist」（begins_with(SK, "WATCHLIST#")）。

對應 knowledge card：hot partition、workload model。

設計流程

從 access pattern 反推 PK/SK 跟 GSI 的 5 步流程。

Step 1：access pattern 表窮舉

每個 user story 寫成一條 query：

1| #  | User story                          | Query                                 | Latency | Consistency |
2| -- | ----------------------------------- | ------------------------------------- | ------- | ----------- |
3| 1  | 顯示用戶 profile                    | GetItem PK=USER#{id} SK=PROFILE       | p99 5ms | eventual    |
4| 2  | 取用戶所有觀看清單                  | Query PK=USER#{id} begins_with(SK, "WATCHLIST#") | p99 10ms | eventual |
5| 3  | 跨裝置同步播放進度（最新）          | GetItem PK=USER#{id} SK=PROGRESS#{movie}#latest | p99 15ms | strong |

15-30 條 query 全列出，這是 single-table 的契約。漏列等於設計時看不到、上線後撞。

Step 2：entity-relationship → PK/SK 映射

常見模式：

• 主 entity 用 {ENTITY}#{id} 當 PK（USER / ORDER / PRODUCT）
• 子 entity 用同 PK + 不同 SK 前綴（PROFILE / ORDER#{timestamp} / ITEM#{id}）
• 1-N 關係（user 有多個 watchlist）用同 PK + 不同 SK
• N-N 關係（user 跟 friend）用兩條 item（A→B 與 B→A）或單獨 relationship entity

Step 3：GSI 補反向查詢

主 PK 覆蓋不到的 access pattern 用 GSI 補：

• 「依 status 查所有 order」→ GSI PK = status、SK = created_at
• 「依 product 查所有買家」→ GSI PK = product_id、SK = user_id

GSI 數量上限 20、實務 < 5；過多時表示主 PK 設計沒覆蓋夠多 access pattern、應重新設計。詳見 gsi-lsi-design。

Step 4：CloudFormation / Terraform DDL

 1Resources:
 2  SingleTable:
 3    Type: AWS::DynamoDB::Table
 4    Properties:
 5      BillingMode: PAY_PER_REQUEST
 6      AttributeDefinitions:
 7        - AttributeName: PK
 8          AttributeType: S
 9        - AttributeName: SK
10          AttributeType: S
11        - AttributeName: GSI1PK
12          AttributeType: S
13        - AttributeName: GSI1SK
14          AttributeType: S
15      KeySchema:
16        - AttributeName: PK
17          KeyType: HASH
18        - AttributeName: SK
19          KeyType: RANGE
20      GlobalSecondaryIndexes:
21        - IndexName: GSI1
22          KeySchema:
23            - AttributeName: GSI1PK
24              KeyType: HASH
25            - AttributeName: GSI1SK
26              KeyType: RANGE
27          Projection:
28            ProjectionType: INCLUDE
29            NonKeyAttributes: [status, created_at]

Step 5：驗證點

• 每個 access pattern 對應一個 Query / GetItem、沒有 Scan、沒有 application-side join
• Contributor Insights 看 top-N PK 訪問是否均勻
• CloudWatch ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits 按 partition 分布觀察

Rollback boundary：access pattern 改動可加 GSI 補；entity 拆 table 比合 table 容易，先合再拆。

失敗模式

5 個 production 常見踩雷：

Case 1：late-binding access pattern

production 上線半年後 PM 要新 query「按地區列訂單」、PK 沒包 region、只能 Scan 或加 GSI。根因是 access pattern 沒在設計階段窮舉，這是 single-table design 的核心責任。修法：access pattern 表列完整、不可省略；新需求進來先回 access pattern 表 review、再決定加 GSI 還是重設計 PK。

Case 2：SK 排序衝突

同 PK 下兩種 entity（ORDER#{timestamp} 與 PAYMENT#{timestamp}）混用同 SK 空間、range query 拿 BETWEEN '2026-01-01' AND '2026-12-31' 時 entity 邊界錯亂。修法：SK 前綴必須能 用 begins_with 完全區隔 entity（ORDER#2026-... vs PAYMENT#2026-...）。

Case 3：item collection 超過 10GB

單 PK 下所有 item 加起來超過 10GB 上限、DynamoDB 拒絕新寫入。常見於「user 為 PK + user 有大量歷史 event」場景。修法：歷史 event 改用 USER#{id}#YYYYMM 當 PK 把時間 bucket 切開、或把歷史 event 寫進另一張 archive table（cold path）。

Case 4：GSI 反向變主表

開始 GSI 只補 1-2 個 query，半年後 GSI 流量超過主表、cost 翻倍。根因是主 PK 沒設計好、GSI 變成 實質的主存取路徑。修法：重新設計 PK、把 GSI 流量主要的 access pattern 升為主表 query；GSI 從多到少要 application 端配合 cutover。

Case 5：DynamoDB 當 RDBMS 用

把 normalize 過的 schema 直接搬、每個 business query 要 2-3 個 GetItem、latency 從 5ms 變 30ms。修法：normalize 適合 SQL、不適合 KV；single-table 是把 normalize 拍平、用 denormalize 換 read latency。

Anti-recommendation：access pattern < 5 個、entity 間關聯弱、查詢仍在探索期 → 用 SQL 或 multi-table 先寫、access pattern 穩定再 single-table。

容量與觀測

CloudWatch metric：

• ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits：按 partition 分布看是否均勻
• ThrottledRequests：早期 hot partition 訊號（provisioned 模式立即可見）
• SuccessfulRequestLatency p99：on-demand 模式下 hot partition 表現為 latency spike（見 partition-key-antipatterns 的 mode × partition 交叉判讀）

Contributor Insights：top-N partition key 訪問頻率，揭露 single-table 設計後是否仍均勻；每月 cost ~$0.02 per million event、值得開。

GSI 觀測：每個 GSI 獨立 RCU/WCU、projection type（KEYS_ONLY / INCLUDE / ALL）決定 storage cost。

TTL 是 storage cost 防爆的標配（特別在 message-class workload）— PayPay 9.C26 揭露 3 億 / 天 × 30 天 = 90 億筆記錄、不清理會撐死 storage 預算；設 TTL attribute 讓 DynamoDB 自動刪過期 item、消耗 0 WCU。

接回 4.20 Observability Evidence Package 跟 9.5 Bottleneck localization。

邊界與整合

Frame 3：DynamoDB 在 fleet 治理 frame 的退化

跨 vendor 共通 frame：production scale 走 fleet of clusters（Aurora 200 cluster / CockroachDB 380+ cluster / MongoDB Atlas 20 DB 都是這個 frame）。DynamoDB 在這 frame 退化得最徹底 — 不走 fleet of clusters、是用 partition 內部自動切。

對照其他 vendor：

DynamoDB 退化點：partition 是 vendor 內部物理層、不暴露給應用 — application 看到的永遠是「一張 table」、不需要規劃 cluster boundary。代價是 partition key 設計責任全壓在 schema 上（partition-key-antipatterns）、不能用「拆 cluster 解 blast radius」當逃避路徑。

例外情境：DynamoDB 在 合規場景 仍可能走「多 table per market」拓樸（見 Frame 5 global-tables-conflict region-pinned 段）— 但動機是合規 boundary 而非 capacity scale、跟 Aurora fleet driver 結構不同。

DynamoDB 在系統中的角色：control plane / metadata / state

DynamoDB 不是 universal store、不是 SQL 替代品。3 個 case 重複揭露同一定位：

• 9.C18 Zoom：媒體串流走 P2P + edge servers、DynamoDB 只承擔會議 / 用戶 metadata。control plane 跟 data plane 分離是 30x DAU surge 能撐的工程前提（不是 DynamoDB 自己魔法）。
• 9.C27 Disney+：content 走 S3 + CDN、DynamoDB 只承擔 metadata / watchlist / cross-device 進度。
• 9.C19 Capcom：EKS 跑 game server / 處理即時遊戲邏輯、DynamoDB 處理持久狀態。

Durable queue / write-buffer 作為正向非 OLTP access pattern

9.C15 Tixcraft 揭露 DynamoDB 的另一種正向用法 — 寫入緩衝層、不是 OLTP：

• 拓元用 DynamoDB 接「訂單」寫入、不是即時生效、是讓 traditional server（金流 / 票庫）用自己能承受的速度消費
• 架構上 DynamoDB 扮演 durable queue、不是傳統 OLTP DB；這層解耦讓「前端可擴 130 倍、後端不用同步擴」
• 對比 RDBMS：RDB 寫入要即時可讀、即時索引、即時 transaction commit；DynamoDB 寫入可以「先 durable、之後處理」
• 寫進你的設計時要明示：這是 非預設 access pattern、是 flash-sale / 高峰寫入解耦的工程選擇、不是 DynamoDB 預設定位

這個 access pattern 跟 single-table 設計兼容 — PK 仍是 event_id#shard、SK 是 ORDER#{user_id}#{timestamp}、寫入時直接寫，後端傳統 server 慢消費；只是讀路徑是 後端服務 batch 取 而非 user-facing query。

RDB connection limit 機制對照

9.C29 Lemino 揭露為什麼 DynamoDB 在 surge 下不會踩 RDB 的隱性天花板：

• 「connection limits became bottlenecks when experiencing a rapid increase in access」— PostgreSQL/MySQL 每連線吃記憶體 / process、pool 上限 1K-5K、connection 是 RDB 在 surge 下 第一個爆點（不是 CPU / disk）
• DynamoDB 的 HTTP API（無 long-lived connection state）天然解這個問題；client 不需要維護 connection pool、AWS SDK 用 connection-less HTTP request

選 DynamoDB 不只是 schema 選擇、是 connection model 選擇。single-table 設計 外部 的容量優勢、寫進邊界判讀條件。

Sibling 與 cross-link

• partition-key-antipatterns — 軸 1 不天然均勻時的 composite key 補救
• gsi-lsi-design — 主 PK 覆蓋不到的 access pattern 補位
• on-demand-vs-provisioned — access pattern 影響 capacity mode 選擇
• consistency-model-optimization — 軸 3 的 per-call site review
• global-tables-conflict — 跨 region 多寫入時 single-table 仍適用、但 conflict resolution 加一層
• 反向路由：access pattern 探索期 / strong consistency 必要 / data plane workload → 回 PostgreSQL vendor

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

售票網站開賣前一小時把 DynamoDB capacity 從 200 WCU 拉到 5000、心想「容量加 25 倍應該夠」。開賣瞬間還是看到 ThrottledRequests 拉警報、CloudWatch 顯示總 capacity 才用了 1500 WCU。打開 partition-level metric 才看到某一個 partition 已經達到 1000 WCU 上限、其他 partition 閒置 — event_id 當 PK、單一熱門場次把所有寫入集中到同一個 partition。Capacity 加再多都救不了，因為單 partition 上限是 1000 WCU / 3000 RCU、跟 table 總容量無關。這就是 hot partition 的本質：partition key 設計問題、不是 capacity 不夠。

本文展開 partition key 反模式的識別、composite key / write sharding 兩種修法、mode × partition 在 provisioned / on-demand 下的不同表現、以及 9.C15 拓元 6750x IOPS 擴展案例的工程細節。

DynamoDB 適用度前置判讀：本篇假設 workload 已通過 DynamoDB 適用度 4 軸（PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定）— 詳見 single-table-design-pattern 開頭 4 軸前置判讀、本篇不重複展開。Partition key 反模式是 已選 DynamoDB 後 的 schema 修補議題；若 4 軸不成立、改回 SQL 比補 composite key 更合理。

跨 vendor 可逆性對照 SSoT：MongoDB / DynamoDB / Cosmos DB 三家 partition key 可逆性不在同一光譜（DynamoDB 走 backfill 到新 table、屬中度可逆）、跨 vendor 對照 SSoT 主寫位置在 DB3 entry — 三 vendor 對比 10 軸 + 對應的軸的延伸子段。本篇聚焦 DynamoDB 內部如何識別 partition key 反模式 + composite key / write sharding 修法、不重複跨 vendor 比較。

核心機制：partition 上限是工程硬天花板

DynamoDB 把 capacity 抽象成 RCU / WCU、但底下仍是物理 partition。理解 partition 的 4 條硬規則：

• 單 partition 上限：3000 RCU、1000 WCU、10GB storage；超過任一個觸發 partition split
• 總容量公式：partition 數量 × 每 partition 上限、partition 數量由 vendor 自動管理
• Adaptive Capacity：跨 partition 重新分配閒置容量、但 單 partition 仍硬上限；不解 single-key 集中
• Splitting on heat：vendor 偵測 hot partition 後自動 split、有分鐘級延遲；突發流量來不及 split 就先 throttle

9.C5 Amazon Ads 揭露同一 frame：「容量 = 每 partition 上限 × partition 數量、最熱 partition saturation 是工程天花板」。Amazon Ads 90M reads/sec 不是把單 partition 推到極限、是 partition key 設計讓流量散到極多 partition、每個 partition 都在合理區間。

對應 knowledge card：hot partition、database-sharding。

Mode × Partition 交叉判讀

Hot partition 在 capacity mode 不同下表現不同、但根因都是 schema。這是 single-table / partition-key / capacity-mode 三篇 deep article 的交叉軸 — mode 切換不解 partition 設計問題、partition 設計也不解 mode 選擇問題。

9.C15 Tixcraft 警惕段明示這個 frame：「DynamoDB 寫入排隊本身就是隱性限流」— provisioned 看得到、on-demand 看不到，但都是同一個 schema 問題。

核心 frame：on-demand 不是 partition key 設計的逃避路徑。看到 on-demand 模式 latency spike 但 throttle 為零，第一個懷疑就是 hot partition、不是網路或應用層。

跟 on-demand-vs-provisioned 共軸閱讀：本篇從 schema 視角切入、那篇從 mode 選擇視角切入、合起來才是完整判讀。

修復流程

從 access pattern audit 到 composite key 設計的 5 步流程。

Step 1：識別寫入集中的 logical key

審視 access pattern 表、抓出 寫入集中 的 key：

• 單一 event / single user 寫入比例 > 10%（如熱門場次售票、bot 帳號）
• 時間 bucket（PK = date / PK = hour）— 寫入永遠打當下 partition、舊 partition 閒置
• 少數枚舉值（PK = status / PK = country 但只有 5-10 個值）

9.C15 Tixcraft 揭露的具體場景：演唱會某一熱門場次的 event_id 為 PK、開賣瞬間 200K 用戶同時搶該場次、所有寫入集中到單一 partition。

Step 2：選 shard 數

把單一 logical key 切成 N 個物理 shard。N 的估算邏輯：

1單 partition WCU 上限 = 1000
2留 20% buffer            = 800
3N = 單 logical key 預期峰值 WCU / 800（最小 shard 數）

Scope warning：「shard 數 10-100」、「800 WCU 留 buffer」這些具體數字是通用工程估算、9.C15 case 沒有 揭露 Tixcraft 用幾個 shard。case 揭露的是「composite key 分散」概念跟「IOPS 從 20 衝到 135K」的結果、不是具體 shard 數量。寫進你自己的設計時、shard 數依預期單 logical key 峰值估算、不要照搬本文數字。

Step 3：composite key 設計（random shard）

Composite Partition Key 把 logical key 加上 random suffix、把 hot logical 值分散到多個 partition：

1import random
2
3def write_order(event_id: str, user_id: str, order_data: dict):
4    # 寫入端：random suffix 分散到 N shard
5    shard = random.randint(0, N - 1)
6    pk = f"{event_id}#{shard}"
7    sk = f"USER#{user_id}#{timestamp}"
8    table.put_item(Item={"PK": pk, "SK": sk, **order_data})

讀取時 fan-out 到所有 shard：

1def query_event_orders(event_id: str):
2    results = []
3    for shard in range(N):
4        pk = f"{event_id}#{shard}"
5        page = table.query(KeyConditionExpression=Key("PK").eq(pk))
6        results.extend(page["Items"])
7    return results

Step 4：calculated shard（讓同 user 仍可預測讀取）

random shard 的代價是讀取要 fan-out N 次。當你需要「同 user 寫入分散、但讀取 該 user 自己的資料時不要 fan-out」、改用 calculated shard：

 1import hashlib
 2
 3def shard_for_user(user_id: str, n: int) -> int:
 4    h = hashlib.md5(user_id.encode()).hexdigest()
 5    return int(h, 16) % n
 6
 7def write_user_event(user_id: str, event_data: dict):
 8    shard = shard_for_user(user_id, N)
 9    pk = f"USER#{user_id}#{shard}"
10    # 同一 user_id 永遠拿到同一 shard

讀單一 user 只 query 一個 shard、讀全平台 user 才 fan-out N 個 shard。

選擇：

• random shard：寫入完全均勻、但所有讀路徑都要 fan-out；適合 flash-sale / 緩衝層（讀路徑是後端慢消費、不在乎 fan-out latency）
• calculated shard：寫入按 hash 均勻、user-level 讀路徑單 shard；適合 user-facing OLTP（user 讀自己資料延遲敏感）

Step 5：驗證點

• Contributor Insights 看 top-N PK 訪問是否平均分布
• CloudWatch partition-level throttle = 0
• Application 端 read fan-out latency 在預算內

Rollback boundary：composite key 寫入端可雙寫舊 + 新 key 一段時間（雙寫窗口）、application read 端 fallback 到舊 PK；不可逆動作只在「移除舊 key」階段。

失敗模式

production case 揭露的 5 個踩雷情境：

Case 1：時間序 PK 集中

PK = date 或 PK = hour — 寫入永遠打當下 partition、舊 partition 閒置。每日凌晨換 partition 時瞬間冷啟動、寫入 latency spike。修法：date#shard 把當下 partition 拆 N 個物理 shard、或改用 event-stream pattern（每個 event 獨立 ID 為 PK）。

Case 2：bot user 集中

PK = user_id、某個 bot 帳號每秒寫 1000 次、單 user_id 達 1000 WCU 上限。修法：

• 偵測高頻 user 後動態加 shard suffix（user_id#shard0 … user_id#shardN）
• 或在 application 層 rate limit、不讓 bot 直接打 DynamoDB

Case 3：composite key 但 read 端忘記 fan-out

寫入分散到 100 shard、讀取只 query 一個 shard、結果不完整。修法：讀取必須 N 次 query 並 application 端合併、或建反向 GSI（GSI PK = event_id、不加 shard suffix；但 GSI 自己也會 hot partition）。

Case 4：shard 數選太多 read fan-out latency 爆

N 過大時讀取 fan-out latency 從 5ms 變 200ms（具體數字隨網路延遲跟並行度變動、9.C15 case 未揭露 Tixcraft 用幾個 shard）。修法：shard 數依「單 logical key 預期峰值 / 800」估算、不是越多越好；read latency 跟寫入分散度是 trade-off。

Case 5：on-demand 模式以為不會 hot partition

on-demand 仍受單 partition 1000 WCU 限制、只是 throttling 表現為 latency spike 而非 exception。team 看到「沒有 ThrottledRequests」就以為沒問題、實際 p99 已經從 5ms 跳到 50ms。修法：on-demand 不是 partition key 設計的逃避路徑、依然要做 composite key；觀測上看 SuccessfulRequestLatency p99 不只看 throttle。跟 on-demand-vs-provisioned 共軸閱讀。

Anti-recommendation：access pattern 寫入分散自然均勻（如 UUID 為 PK、無 logical hot key），不要預先 sharding；增加 read 端 fan-out 複雜度沒帶來收益。

容量與觀測

CloudWatch metric：

• WriteThrottleEvents / ReadThrottleEvents：按 table 跟 GSI 分；provisioned 模式直接訊號
• SuccessfulRequestLatency p99：on-demand 模式下 hot partition 的訊號（throttle 為零但 latency 跳高）
• partition-level metric 透過 Contributor Insights 看，不是 CloudWatch 預設 panel

Contributor Insights 必開：top-N partition key by access frequency；每月 cost ~$0.02 per million event、值得開。沒開 Contributor Insights 你看不到 partition-level 分布、只能從總 capacity 跟 throttle 反推。

DynamoDB Streams：可用來抓 hot key debugging — 寫入事件落 Lambda 後統計 PK 頻率。

Mode × partition 觀測差異（重申交叉判讀）：

• Provisioned 模式：看 WriteThrottleEvents、立即可見
• On-demand 模式：看 SuccessfulRequestLatency p99、看 partition-level Contributor Insights、看 application 端 timeout / retry trend

接回 9.4 Saturation Discovery 的 partition 章節。

邊界與整合

9.C15 Tixcraft 6750x 擴展的工程拆解

9.C15 Tixcraft 揭露的數字：IOPS 從 20 衝到 135K（6750 倍）、6 servers 變 800 servers、總成本 $4200、throttle rate 0.26%。但「6750x 擴展」不是 DynamoDB 自己的魔法、是 partition key 均勻分散 + 架構解耦 的組合結果：

• partition key 均勻：composite key（event_id 加分散 suffix）把單一熱門場次散到多個 partition、每個 partition 都在合理區間（case 揭露概念、未揭露具體 shard 數）
• 架構解耦：DynamoDB 當 durable queue、後端傳統 server（金流 / 票庫）用自己節奏消費、不被前端 130x 流量拖垮（見 single-table-design-pattern 的 durable queue 段）
• 付款層獨立：付款不是 DynamoDB、是另一層獨立服務、避免搶票流量影響付款

讀者該學的不是「DynamoDB 能撐 6750x」、是「composite key + 架構解耦 + 服務分層」三件事一起做才能撐。

Sibling 與 cross-link

• single-table-design-pattern — PK 設計上游、本篇是 PK 不天然均勻時的補救
• on-demand-vs-provisioned — capacity mode 對 hot partition 表現的影響、mode × partition 交叉判讀的另一視角
• gsi-lsi-design — GSI 自己也會 hot partition、GSI PK 設計獨立 review
• Migration playbook：composite key migration 屬「topology re-layout」、寫入需雙軌；對應 migration playbook methodology
• 跟 Tixcraft 9.C15 互引：售票模式的 6750x 擴展細節、composite key 是工程選擇而非 vendor 魔法
• 跟 Amazon Ads 9.C5 互引：容量 = 每 partition 上限 × partition 數量、最熱 partition saturation 是容量天花板
• 跟 Lemino 9.C29 互引：connection-free scale 的另一面是 partition 設計責任

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

single-table design 上線後第三個月、PM 提了三個新 query 需求：「依商品分類查訂單」、「依 status 查 user」、「依時間 range 取最近活動」。team 第一反應是加 GSI、結果 GSI 從 1 個變 6 個、cost 跟 latency 一起上升。打開 AWS Cost Explorer 一看、GSI 的 storage + WCU 合計已經超過 base table。這時 team 開始懷疑「single-table 是不是錯了」— 那是 誤判。GSI 多到 cost 超過 base table 通常是 主 PK 沒設計好、不是 single-table 錯。本文展開 GSI / LSI 的正確補位、projection 的三型選擇、sparse index、以及 DAX 作為讀峰值補位的觸發條件。

DynamoDB workload 適配判讀（基本 4 軸）：PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定 — 判讀軸詳見 single-table-design-pattern 開頭 4 軸前置判讀。本文聚焦 GSI / LSI 補位操作層、是 已選 DynamoDB + access pattern 已穩定 的 schema 設計議題。

核心機制：GSI vs LSI 的工程差異

DynamoDB 的兩種 secondary index 解的問題不同：

Scope warning：「LSI 數量上限 5 個」、「GSI 數量上限 20」這些具體數字屬 vendor 規格、需在實作時 cross-verify AWS doc 當前數字、本文 case（Disney+ / Capcom / Lemino）沒揭露具體 index 數量。

Projection type 決定 GSI 儲存哪些 attribute：

• KEYS_ONLY：只存 PK + SK + base key、最省 storage、但讀取後通常還要回 base table 撈 attribute
• INCLUDE：除了 key、再存指定的 attribute；常用 sweet spot、storage 跟 query 效率平衡
• ALL：複製 base table 所有 attribute；最方便、最貴

讀路徑差異：

• GSI eventual read：跨 partition、不支援 strong；base table write → GSI replication 通常 < 1s 但無 SLA
• LSI strong read：同 partition quorum 內成立、read-your-write 場景適用

對應 knowledge card：hot partition、consistency level。

DAX 作為讀峰值補位

DAX（DynamoDB Accelerator）不是 GSI / LSI 同層方案、不是 DynamoDB 預設配置、是「讀峰值持續高時的補位」。寫進你的設計前先看觸發條件：

9.C29 Lemino 揭露（case fact）：「DAX 是 DynamoDB 讀 cache 的標準解法」、觸發條件是「當讀峰值持續高、加 DAX 減少 DynamoDB 讀次數、降低成本」（熱門節目首播時段、共用 metadata）。Lemino 是 case 直接揭露使用 DAX。

9.C19 Capcom 是判讀層 derive、不是 case fact：原 finding 從「single-digit ms」latency 反推 Capcom 必須用 sub-region cache + DynamoDB DAX、不能單靠 DynamoDB；但 9.C19 case 沒有公開揭露 使用 DAX。引用 Capcom 時要明示「DAX 是作者判讀層推論、Capcom 沒公開使用」、避免把推論寫成 case 揭露。

跟 GSI / LSI 的職責分離：

• GSI / LSI 解「無法用主 PK 查」的問題（access pattern 補位）
• DAX 解「同 query 重複打 DynamoDB 太貴或太慢」的問題（讀路徑加速）
• 兩者不互斥、但解不同問題；不要把 DAX 當 GSI 替代品

DAX 適用觸發條件：

• 讀峰值持續高（熱門節目 / 共用 leaderboard / 全平台共享 metadata / read:write ratio > 10:1）
• cache 命中率可預期高（重複讀同一組 key）

DAX 不適用情境：

• 寫密集 workload（cache invalidation 開銷 > cache 收益）
• 每次讀都不同 key（cache hit rate < 30%、加 DAX 等於白花錢）
• read-your-write 場景（DAX 仍是 eventual cache、staleness 視 cache TTL 而定）

設計流程

從 access pattern 補位到 DAX 評估的 6 步流程。

Step 1：標記最小成本路徑

每個 access pattern 標記能用最便宜路徑解：

• 能用主表 PK/SK 直接 GetItem / Query → 主表（最便宜）
• 同 PK 內不同 SK 排序 + 需要 strong read → LSI（同 partition、strong）
• 跨 PK 或 base table 已建好 → GSI（額外 storage + WCU）

Step 2：選 LSI 還是 GSI

LSI 只能在 create table 時定義、不能後加。team 經常踩雷：上線後想加 strongly consistent 索引、發現只能重建 table。建 table 前列完 access pattern、不確定走 GSI 不走 LSI 是保守選擇（GSI 隨時可加可移）。

Step 3：projection 設計

每個 GSI 單獨設 projection、不要全用 ALL：

• query 只要回 key → KEYS_ONLY
• query 需要常見 3-5 個欄位 → INCLUDE（列出實際 column、storage 跟 query 效率平衡）
• 用 GSI 直接顯示資料（不回 base table） → ALL（storage 跟 WCU 都翻倍、慎用）

Step 4：sparse index pattern

GSI PK 只在某 attribute 存在時填、自動「只索引子集」、節省 storage：

1def write_order(order_id: str, status: str):
2    item = {"PK": f"ORDER#{order_id}", "SK": "META", "status": status}
3    # sparse index: 只有 active order 進 GSI
4    if status == "active":
5        item["GSI1PK"] = "STATUS#active"
6        item["GSI1SK"] = order_id
7    table.put_item(Item=item)

GSI1 只索引 active order、archive order 不進 GSI。當 active order 是 10%、storage 節省約 90%。

Scope warning：「50-90% storage 節省」具體節省比例屬通用工程估算、依 active subset 比例變動、case 未揭露 sparse index 具體數字。

Step 5：驗證點

1response = table.query(
2    KeyConditionExpression=Key("GSI1PK").eq("STATUS#active"),
3    IndexName="GSI1",
4    ReturnConsumedCapacity="INDEXES"  # 看每個 query 走 GSI 還是主表
5)
6print(response["ConsumedCapacity"])

CloudWatch GSI metric：看每個 GSI 的 WCU usage 跟主表的比例；GSI WCU > base table WCU 通常是設計訊號。

Step 6：DAX 評估

讀峰值持續高 + cache hit rate 可預期、才加 DAX；不要把 DAX 當預設配置（Lemino 揭露的觸發條件）。先觀察 base 路徑的 read pattern、判斷 cache hit rate 預期值、再決定加 DAX。

Rollback boundary：GSI 可隨時刪、但 deletion 是 async 且不可逆；建議先 application 切回 base table query、觀察 1 週再刪 GSI。DAX 可隨時 detach、application 端把 DAX endpoint 換回 DynamoDB endpoint 即可。

失敗模式

7 個 production 常見踩雷：

Case 1：GSI 寫入 throttle 拖累主表 write

GSI 用了集中型 PK（如 STATUS#active 所有 active order 集中）、單 partition 上限 1000 WCU 撞牆、GSI replication 失敗、主表 write retry、整體 latency 上升。修法：GSI PK 設計獨立 review、不可繼承主表 PK 的均勻假設（base PK 均勻 ≠ GSI PK 均勻）；GSI PK 也要做 partition key 均勻度判讀。

Case 2：GSI eventual read 餵錯資料

application 用 GSI 讀「user 最新 status」、code 假設 strong 一致；實際 100-500ms staleness 導致 UI 顯示舊狀態。修法：read-your-write 場景改回主表 query（主表支援 strong）、或加 application-side write-through cache。

Scope warning：「100-500ms staleness」具體數字屬通用工程估算、case 未揭露 GSI replication latency 具體 p99 數字。

Case 3：projection ALL 把 cost 翻倍

圖省事所有 GSI 用 ALL、實際 query 只需要 3 個 column；storage + WCU 都浪費。修法：每個 GSI 單獨設 projection、INCLUDE 列出實際 column；只在「用 GSI 直接顯示資料、不回主表」場景才用 ALL。

Scope warning：「cost 翻 3 倍」具體數字屬通用工程估算、case 未揭露具體 cost ratio。

Case 4：LSI 用完了才發現要的是 GSI

LSI 上限受 vendor 規格限制（建議 cross-verify AWS doc 當前數字）且建 table 時定、半年後想加 strongly consistent 索引發現要重建 table。修法：建 table 前列完 access pattern、不確定就走 GSI（隨時可加可移）；LSI 留給「明確需要同 PK + strong read」場景。

Case 5：GSI 反向 scan 取代 query

application 用 GSI 做 Scan 而非 Query、全 GSI 掃過去、cost 跟 latency 都炸。修法：Scan 是 程式碼錯誤訊號、不是 capacity 不夠；review code 看 GSI 為什麼沒被當 query 路徑用、通常是 GSI PK 設計沒對齊 access pattern。

Case 6：把 DAX 當預設配置

寫密集 workload / cache hit rate 低的場景加 DAX、cache invalidation 成本超過 cache 收益、cost 上升 latency 沒降。修法：DAX 是「讀峰值持續高」的補位、不是預設（Lemino 揭露的觸發條件、Capcom 是 derive 不是 case fact）；先觀察 read pattern + 評估 cache hit rate 預期、再決定。

Case 7：GSI capacity mode 跟 base table 不一致

GSI 的 capacity mode 跟 base table 是 獨立 設定、不會自動繼承 — base table 是 provisioned + auto-scaling、開新 GSI 預設仍是 provisioned 但 WCU / RCU 預設值跟 base table 不同步、或誤把某個 GSI 切 on-demand 而 base table 維持 provisioned、實際 production 寫入 throttle / 成本失衡都會出現。屬通用工程議題、case 未直接揭露具體 mode 錯配狀況。

徵兆：

• Base table ConsumedWriteCapacityUnits 健康、卻看到 GSI WriteThrottleEvents 持續觸發、application 端寫入 latency p99 拉高
• GSI 切 on-demand 後成本「不知為何」翻 X 倍、查 Cost Explorer 才發現 GSI WCU 計費跟 base table 的 provisioned 是完全不同帳單路徑
• Auto-scaling policy 只設了 base table、GSI 沒設、流量上來時 base table 自動擴、GSI 卻 throttle

修法：

• 建 GSI 時把 capacity mode 當成獨立決策、不要假設「base 怎麼設、GSI 跟著走」
• 流量穩定 workload 同時把 base + GSI 都設 provisioned + auto-scaling、auto-scaling target 對齊
• Spiky workload 改 on-demand 時整批切（base table + 全部 GSI 同時切）、避免單側切換造成 partial throttle
• CloudWatch alarm 對每個 GSI 獨立設 WriteThrottleEvents / ReadThrottleEvents、不要只盯 base table
• 詳細 mode 切換時機看 sibling on-demand vs provisioned

Anti-recommendation：access pattern < 3 個、主表 PK 已能覆蓋 → 不要預先建 GSI；GSI 從少到多容易、從多到少要 application 端配合 cutover。

容量與觀測

CloudWatch metric：

• 每個 GSI 獨立 ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits
• ReplicationLatency：GSI async replication 延遲、p99 通常 < 1s（無 SLA）
• DAX：CacheHits / CacheMisses / CacheHitRate、ItemCacheHits / QueryCacheHits

ReturnConsumedCapacity flag：query 時帶 INDEXES 看 GSI consumption；TOTAL 看 base + GSI 合計、debug 時切換用。

Cost monitoring：

• 每個 GSI 都重複收 storage + WCU；GSI 多時 cost 容易超過 base table
• 用 AWS Cost Explorer 按 GSI 維度看、不是只看 table-level 總 cost
• DAX cost 是 instance-hour 計、不是 per-request；只在 read peak 持續高才划算

Scope warning：「GSI 多時 cost 超過 base table」屬通用工程知識、9.C27 Disney+ / 9.C19 Capcom case 沒揭露具體 GSI cost ratio。

DAX 觀測重點（新增）：

• CacheHitRate < 70% 應重新評估 DAX 是否該存在
• cache size utilization 看 DAX instance class 是否足夠
• 觀察 cache miss 後 fallback 到 DynamoDB 的 latency、確認 DAX 真的減少 base 路徑壓力

Scope warning：「70% hit rate 閾值」屬通用工程估算、case 未揭露具體閾值。

接回 9.6 容量規劃模型 的 NoSQL index cost section、4.20 Observability Evidence Package。

邊界與整合

Disney+ / Capcom 的 access pattern 對照

9.C27 Disney+ 跟 9.C19 Capcom 是兩種 GSI 用法：

• Disney+ watchlist + 播放進度 + cross-device sync 全用主表 + 少量 GSI、避免 GSI 爆炸；cross-device sync 透過 Global Tables 處理、不是 GSI
• Capcom 玩家 leaderboard / 戰績用 GSI 反向查詢（跨遊戲共用平台、player_id 為 base PK、game_id 為 GSI PK）；leaderboard 是否該走 GSI 還是 Redis sorted set 是另一個取捨

兩個 case 都 沒有公開揭露 具體 GSI 數量、projection 配置、DAX 是否使用。引用 case 時要分層 — 概念是 case 揭露、實作數字是通用工程估算。

Sibling 與 cross-link

• single-table-design-pattern — GSI 是 single-table 沒覆蓋的 access pattern 補位
• partition-key-antipatterns — GSI 自己也會 hot partition、GSI PK 設計獨立 review
• consistency-model-optimization — GSI 強制 eventual、對應 consistency 軸
• on-demand-vs-provisioned — GSI 多時 cost 跟 mode 互動
• 替代路由：access pattern 變動頻繁 → 考慮 OpenSearch / Aurora、單純 search 不要拿 GSI 當 inverted index
• 跟 Capcom 9.C19 互引：leaderboard 用 GSI vs Redis sorted set 的選擇；DAX 是 derive 不是 case fact、引用要明示
• 跟 Lemino 9.C29 互引：DAX 作為讀峰值補位的 case 揭露

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

quarterly review 看 DynamoDB bill 突然漲 80%、追查發現是 dev team 把所有 table 切 on-demand「省 capacity 管理」。finance 反問「於是省了多少 SRE 工時、又多花多少 cost」、team 答不出來。反向情境：Black Friday 前一週 provisioned table auto-scaling 上限是日常 5 倍、但開賣瞬間流量是 50 倍、auto-scaling 反應週期 5 分鐘、前 10 分鐘大量 throttle。兩個 production 痛點指向同一件事 — capacity mode 選擇不能只看「peak/avg ratio > 5x」單軸閾值。

本文展開 6 軸決策（peak/avg / 讀寫比 trend / surge 性質 / 事件分級 / DBA 工時釋放 / vendor crossover），把單軸決策樹擴成完整判讀框架。

DynamoDB 適用度前置判讀：本篇假設 workload 已通過 DynamoDB 適用度 4 軸（PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定）— 詳見 single-table-design-pattern 開頭 4 軸前置判讀、本篇不重複展開。Capacity mode 選擇是 已選 DynamoDB 後 的成本決策；若 workload 不適用 DynamoDB、mode 選擇無法救回 vendor 選錯的成本。

核心機制：兩種 mode 的工程差異

Auto-scaling 內部機制：

• CloudWatch alarm 觸發 → scaling activity → 1-5 分鐘調整 capacity
• target utilization 70%（建議值、留 buffer 給 scale latency）
• 連續 spike 仍可能 throttle（auto-scaling 反應週期 > spike 速度）

對應 knowledge card：peak forecast、cost per request、scheduled scaling。

6 軸決策框架

mode 選擇不是單軸 peak/avg ratio。下面 6 軸是 9 個 production case（Zomato / Zoom / Amazon Ads / Disney+ / Tixcraft / Capcom / Lemino / Genesys / PayPay）跨 case 揭露的真實決策維度。

軸 1：peak / average 流量 ratio

最直覺的軸、但是單軸誤判的根源。基本判讀：

• 高 ratio（spiky / flash-sale）傾向 on-demand
• 穩定 ratio（sustained / 平緩）傾向 provisioned + auto-scaling

Scope warning：「peak/avg > 5x → on-demand」、「provisioned base rate × 6-7 = on-demand rate」這些具體閾值是經驗值 / 通用工程估算、9.C5 / 9.C20 case 都沒給具體 ratio 數字。實際 crossover 點隨 region pricing + workload shape 變動、不要照搬本文數字。

軸 1 單獨不夠用、要跟軸 2-6 合成判讀。

軸 2：讀寫比 trend 變化

9.C5 Amazon Ads 揭露的觀測軸：「讀寫比 變化 比讀寫比本身更重要」。

• 絕對讀寫比對容量規劃不是最重要（C5 是 18:1、C27 推估 5:1、絕對值各家不同）
• 業務邏輯改變（新增即時報表 / 新增推播 / 新增分析 query）會讓讀寫比跳一個量級
• 觀測上加 metric：read / write ratio 7-day rolling average、超過 ±30% 偏移觸發 review

把 trend 變化當 capacity mode 重新評估的訊號 — 不是固定週期 review、是 trend 偏移 觸發 review。

軸 3：surge 是 暫時 還是 永久 baseline 上移

9.C18 Zoom COVID 30x DAU surge 揭露的軸：surge 後 baseline 永久上移、不會回去。

• 暫時 surge（單日活動 / 季節高峰）：on-demand 划算、活動結束 mode 不用調
• 永久上移後（Zoom COVID、社會行為改變）：原 on-demand 設計會持續燒錢、要重新算 crossover、考慮切回 provisioned

Tripwire：surge 結束後 4-8 週仍維持 surge 期間 baseline 的 70%+、判定為「永久 baseline 上移」、重評 mode。

Scope warning：「4-8 週 / 70% 閾值」屬通用工程估算、9.C18 Zoom case 揭露「surge 後 baseline 不會回去」概念、未揭露具體閾值。

軸 4：predictable-peak vs flash-sale

9.C27 Disney+ 跟 9.C15 Tixcraft 對比揭露的軸：兩種 event-driven peak 不是同一類。

9.C27 Disney+（Marvel / Star Wars 首日 metadata 流量 3-5 倍、持續時段較長）可以提前 1-2 天 pre-scale、scheduled scaling 合適。9.C15 Tixcraft 6750x in seconds，scheduled scaling 太慢、必須事前 pre-provision baseline 拉到極高、或用 on-demand + composite partition key 雙保險。

兩者都不是「peak/avg > 5x → on-demand」單軸決策能解。

Scope warning：「scheduled scaling 30-60 分鐘前升 capacity」這個具體 lead time 是經驗值、case 未揭露具體時間。pre-scale 的 lead time 依事件性質決定、不是固定 30-60 分鐘。

軸 5：DBA / SRE 工時釋放

9.C19 Capcom 跟 9.C29 Lemino 揭露的成本軸：DynamoDB 真實成本不只看 monthly bill。

• 9.C19 Capcom：30% 成本下降的本質是「工程資源從 DB 運維轉到遊戲品質」、Capcom 是遊戲公司不是 IT 公司、把 DBA 時間從 Postgres patching / replication 設定 / backup 排程釋放到遊戲機制設計
• 9.C29 Lemino：90% 工程工時下降（DBA + connection management + capacity planning 統包）

評估公式：

1總成本 = direct cost (monthly bill)
2       + 工程工時機會成本 (DBA 從 patch/replication/backup 釋放出來做的事)

on-demand 的 6-7x base rate 在 DBA 工時釋放下、實質 ROI 可能仍正向（特別在小團隊 / 非 IT 主業公司）。但要算總成本、不是只看 bill。

軸 6：DynamoDB vs 自管 cluster cost crossover

9.C20 Zomato 警惕段揭露的最上層決策軸：mode 選擇之上還有 vendor 選擇。

• 9.C20 Zomato：「成本降 50% 是 當下流量 的對照」、未來流量繼續成長、DynamoDB cost-per-request 成長率比 TiDB 自管 cluster 高、某流量規模後 crossover、自管 cluster 反而便宜
• 不是只在 on-demand vs provisioned 之間挑、是要算「未來 12-24 個月在預期流量下、DynamoDB（不論 mode）vs 自管 cluster 的成本曲線」

判讀分層：

• 小 / 中流量 startup：DynamoDB on-demand 簡單划算、不用糾結
• 大流量 + 流量可預測 + DBA 團隊已存在：自管 cluster crossover 點可能成立、值得算
• 大流量 + 流量不可預測 + 小團隊：DynamoDB managed 仍划算（軸 5 加成）

本軸是 mode 選擇之上的更上層決策、不是每次都展開、但寫進邊界判讀條件。

操作流程

從 workload profiling 到 mode 切換的 8 步流程。

Step 1：workload profiling

用 CloudWatch 過去 30 天 RCU/WCU、算 p50 / p95 / p99 peak、求 peak/avg ratio（軸 1 輸入）+ read/write ratio rolling avg（軸 2 輸入）。

Step 2：surge 性質判讀

• 是暫時 surge 還是永久 baseline 上移（軸 3）— 看 surge 結束後 4-8 週的 baseline trend
• 是 predictable-peak 還是 flash-sale（軸 4）— 看事件時間跟 auto-scaling 反應週期的比例

Step 3：6 軸合成決策

1軸 1（peak/avg）+ 軸 2（讀寫比 trend）+ 軸 3（surge 性質）
2+ 軸 4（事件分級）+ 軸 5（工時機會成本）+ 軸 6（vendor crossover）
3→ provisioned + auto-scaling / on-demand / scheduled scaling 三選一

不是任一軸獨自決定、是 6 軸合成；軸間衝突時優先序：軸 6（vendor）> 軸 5（工時）> 軸 3（surge 永久 vs 暫時）> 軸 4（事件分級）> 軸 1（peak/avg）> 軸 2（讀寫比 trend）。

Step 4：provisioned 配 auto-scaling

 1BillingMode: PROVISIONED
 2ProvisionedThroughput:
 3  ReadCapacityUnits: 100
 4  WriteCapacityUnits: 50
 5
 6AutoScalingSettings:
 7  TargetTrackingScalingPolicy:
 8    TargetValue: 70.0  # target utilization
 9    ScaleOutCooldown: 60
10    ScaleInCooldown: 60
11  MinCapacity: 50      # baseline
12  MaxCapacity: 1000    # baseline × 預期 surge multiplier

target utilization 70% 留 buffer 給 scale latency；alarm 設 5 分鐘觀察窗。

Step 5：scheduled scaling

已知大事件（黑五、開票、新片發布）前預先提升 min capacity、事件後回原值：

1# 黑五前 24 小時把 min capacity 拉到日常 10 倍
2client.put_scheduled_action(
3    ResourceId="table/orders",
4    ScheduledActionName="black-friday-pre-scale",
5    Schedule="cron(0 0 * * ? *)",  # 時間 lead 依事件性質決定、非固定 30-60 分鐘
6    ScalableTargetAction={"MinCapacity": 5000, "MaxCapacity": 50000}
7)

Step 6：mode switch

1aws dynamodb update-table \
2  --table-name orders \
3  --billing-mode-summary BillingMode=PAY_PER_REQUEST

每張 table 24 小時內只能切一次、要計畫 maintenance window。

Step 7：驗證點

切換後第一週對比 cost + throttle metric、確認方向正確：

• cost 變化方向跟預期一致（on-demand 應該變貴 / provisioned 應該變便宜）
• throttle rate 沒上升
• latency p99 沒退化

Step 8：總成本評估（軸 5 + 軸 6）

直接 cost + 工時機會成本 + 對照自管 cluster 的 cost crossover 曲線。Quarterly review 用這個公式、不是只看 monthly bill。

Rollback boundary：on-demand → provisioned 隨時可切、但 baseline 要先 sized 好；切錯方向第一個月可逆、長期累積 cost 不可逆。

失敗模式

production 觀察到的 6 個典型 anti-pattern：

Case 1：on-demand 後 cost 翻 3 倍

dev team 切 on-demand「不用管 capacity」、但 workload 是 sustained constant、on-demand 6-7x base rate 全付出來。9.C5 Amazon Ads 明示「sustained workload 用 provisioned + auto-scaling」。修法：穩定 workload 用 provisioned + auto-scaling（軸 1 + 軸 2）。

Case 2：auto-scaling 跟不上 spike

流量 1 分鐘內 10x、auto-scaling alarm 5 分鐘才觸發、前 4 分鐘全 throttle。修法：peak/avg 高且 spike 突然 → on-demand、或 scheduled scaling 預先升配（軸 1 + 軸 4）；flash-sale 場景 auto-scaling 不夠快、必須 pre-provision。

Case 3：on-demand hot partition 隱藏

on-demand 不顯示 throttle、latency 從 5ms 變 50ms、application timeout retry 加劇問題。修法：on-demand 仍要看 partition-level metric（Contributor Insights）、不能假設 mode 解決設計問題（跟 partition-key-antipatterns cross-link）；mode × partition 交叉判讀。

Case 4：provisioned target utilization 設太高

target = 90% 看似省、實際每次 spike 都先 throttle 再 scale。修法：70% buffer 給 scale latency、不要為了省 cost 把 utilization 推到極限。

Case 5：頻繁切 mode 撞 24h 限制

team 想「白天 provisioned 晚上 on-demand」省 cost、但 mode 切換 24h 一次、計畫破產。修法：白天 provisioned + 晚上把 capacity 設低、不切 mode；用 scheduled scaling 處理日週期、不用 mode switch。

Case 6：surge 後沒重評 mode、長期燒錢（軸 3 對應）

Zoom 式 30x permanent baseline 上移後、原 on-demand 設計成本爆炸。修法：surge 結束 4-8 週後重評、若 baseline 維持 70%+ 改 provisioned；把「surge 後 mode review」寫進 runbook、不是 ad-hoc 才想到。

Anti-recommendation：流量 < 100 RPS、cost < $50/月的小 table 不用糾結 mode、on-demand 簡單；workload 穩定且 cost 高才值得做 provisioned + auto-scaling 的工程投入。

容量與觀測

CloudWatch metric：

• ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits：基本用量
• ProvisionedReadCapacityUnits / ProvisionedWriteCapacityUnits：provisioned 預設值
• ThrottledRequests：provisioned mode 直接訊號、on-demand 為零不代表沒問題
• SuccessfulRequestLatency p99：on-demand mode 下 hot partition 訊號

新增的觀測軸（軸 2 / 軸 3 對應）：

• read/write ratio 7-day rolling avg、超過 ±30% 偏移觸發 review
• surge baseline 4-week rolling avg、判斷 surge 是暫時還是永久
• AWS Cost Explorer 按 table + mode 切 cost trend、月對比

Auto-scaling activity log：CloudWatch alarm history + scaling activity，觀察 scaling 是否頻繁但 utilization 仍低（表示 alarm 設太敏感）。

指標口徑紀律：引用 case 數字時明示口徑 — 9.C5 90M reads/sec 是「年度峰值最高一秒、非平均」、9.C20 90% latency 降可能只 p50 不是 p99/p999、9.C18 30x DAU 是「permanent baseline 上移」非單日 peak。讀 vendor case 數字要分「最大瞬時 / 99 百分位 / 常態 / 滾動」四個口徑、不是混用。

Cost gate：每月 finance review 把 DynamoDB cost 對齊 access pattern volume、不只看絕對數字；軸 5 工時釋放跟軸 6 vendor crossover 也納入。

接回 9.6 容量規劃模型、1.10 KV / Document DB 容量規劃。

邊界與整合

Frame 8 event-driven scaling 5 種模式

9.C5 / 9.C15 / 9.C18 / 9.C24 / 9.C27 跨 case 揭露 event-driven scaling 至少 5 種形狀：

• flash-sale spike：拓元 6750x in seconds（軸 4 走 pre-provision + composite PK）
• predictable peak：Disney+ 新片首發（軸 4 走 scheduled scaling）
• sustained growth：Amazon Ads / Capcom（軸 1 + 軸 5 → provisioned + auto-scaling）
• surge baseline permanent shift：Zoom 30x DAU 不會回去（軸 3 → 重評 mode）
• B2B sustained + 高可用：Genesys 99.999%（軸 5 + 軸 6 → managed 工時釋放比 cost 重要）

不是用「peak/avg > 5x」單一閾值決策、是事件型分類 × 軸合成。

Sibling 與 cross-link

• partition-key-antipatterns — capacity mode 不解 hot partition、mode × partition 交叉判讀
• single-table-design-pattern — access pattern 影響 peak/avg ratio 跟 read/write ratio
• gsi-lsi-design — GSI 多時 cost 跟 mode 互動
• global-tables-conflict — 多 region capacity 規劃放大、軸 5 工時釋放在 multi-region 更顯著
• Migration playbook：跨 vendor cost optimization（如 Zomato TiDB → DynamoDB）對應 type C operational hybrid
• 替代路由：cost 極度敏感 + 流量穩定 + DBA 團隊已存在 → 自管 PostgreSQL / MySQL 可能更便宜（軸 6 crossover）、回 PostgreSQL vendor
• 跟 Zoom 9.C18 互引：30x permanent surge 後的 mode 重評（軸 3 主案例）
• 跟 Capcom 9.C19 + Lemino 9.C29 互引：DBA 工時釋放（軸 5 主案例）
• 跟 Aurora read-replica-scaling 共軸 cross-link：本篇從 KV 層 mode 選擇切入、5 模式分類在本篇主寫；Aurora 從 SQL 讀副本視角切入、事件分級表（FanDuel 平日 / playoff / championship / Super Bowl）跟雙 SLO 並行（DraftKings 讀寫雙峰錯位）+ fleet 治理在 Aurora 端主寫、本篇不重複展開

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

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

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

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

B2B SaaS vs B2C 業務 driver 對比

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

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

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

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

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

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

正向 access pattern：不只 conflict 議題

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

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

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

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

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

核心機制：LWW conflict resolution

Global Tables 的 first-class concept：

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

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

設計流程

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

Step 1：access pattern 分類

把 table 中的資料分兩類：

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

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

Step 2：啟用 Global Tables

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

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

Step 3：application 寫入策略

兩種寫入策略：

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

選擇：

Step 4：idempotency 設計

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

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

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

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

Step 5：conflict detection

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

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

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

Step 6：reconciliation pipeline

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

merge logic 視業務而定：

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

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

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

失敗模式

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

Case 1：LWW 默默吃掉 write

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

Case 2：Clock skew 讓 LWW 倒置

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

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

Case 3：Replication lag 撞 SLO

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

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

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

Case 5：跨 region transaction 失敗

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

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

容量與觀測

CloudWatch metric：

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

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

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

Cost monitoring：

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

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

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

邊界與整合

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

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

跨 vendor 對照：

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

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

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

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

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

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

Sibling 與 cross-link

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

本文是 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 — 寫一致性失守後的對帳與修復

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

熱門節目首播時段、application 對同一批 metadata item 的讀取 latency p99 從 5ms 尖到 40ms、下游 timeout 連鎖。team 加了 DAX、p99 壓回個位數毫秒。三個月後另一個 service 也「照抄」加 DAX、結果 cost 上升、latency 沒降 — 那個 service 是寫密集、每次讀的 key 都不同、cache hit rate 不到 20%。同一個工具、在一個 workload 壓回 p99 延遲、在另一個只增加成本卻不降延遲。DAX 的價值取決於 read pattern 跟一致性需求是否匹配。本文展開 DAX 的 cluster 架構、兩種快取的不同失效語意、以及 write-through 跟 strongly consistent read 的邊界。

DAX 觸發條件 SSoT：DAX 「該不該存在」的觸發條件（讀峰值持續高 / cache hit rate 可預期 / read:write ratio 高）主寫於 gsi-lsi-design 的 DAX 段、含 9.C29 Lemino case fact 跟 9.C19 Capcom derive 分層。本文承接「已決定要用 DAX」之後的機制、配置與失效邊界、不重複展開觸發判讀。

核心機制：DAX cluster 與兩種快取

DAX（DynamoDB Accelerator）是 DynamoDB 前面的 in-memory write-through cache、提供 microsecond 級讀取（DynamoDB 本身是 single-digit ms）。它 API 相容 — application 把 DynamoDB client 換成 DAX client、API call 不變、讀寫自動經過 cache 層。

cluster 拓樸：

• 一個 DAX cluster 由多個 node 組成、一個 primary（接受寫）+ 多個 read replica
• 跨多 AZ 部署、primary 故障時 replica 接手
• application 透過 DAX endpoint 連 cluster、SDK 自動分散讀取到 replica

兩種快取、不同生命週期：

這張表的第二列是 DAX 最常被誤解的點：query cache 不會因為底層某筆 item 被改而失效。item cache 走 write-through、寫入時會更新；但 query cache 存的是「整個結果集」、DAX 無法知道某筆新寫入是否該進某個已快取的 query 結果、所以 query cache 只靠 TTL 過期。這代表 query 結果可能 stale 到一個 TTL 週期。

Scope warning：「item cache 預設 TTL 5 分鐘」、「query cache 預設 TTL 5 分鐘」這些預設值屬 AWS vendor 規格、可在 cluster 設定調整、實作時 cross-verify 官方 doc。本文不含 production case 揭露的 DAX TTL 配置數字。

對應 knowledge card：cache-invalidation、write-through-cache、ttl、cache-hit-rate。

一致性與 invalidation 邊界

DAX 的一致性語意是它跟「一般 cache-aside」最大的差別、也是踩雷集中區。

write-through 的保證範圍：

寫入經過 DAX 時、DAX 先寫 DynamoDB、成功後更新自己的 item cache。所以「寫完馬上用 GetItem 讀同一筆」、在 同一個 DAX node 上能讀到新值。但這不是 strong consistency — 多 node cluster 下、寫入只更新 primary 與被路由到的 node、其他 read replica 的 item cache 仍可能 stale 到 TTL。

strongly consistent read 繞過 cache：

DAX 只服務 eventually consistent read。application 若要求 strongly consistent read（ConsistentRead=True）、DAX 直接 pass through 到 DynamoDB、不經 cache、也享受不到 microsecond latency。這是設計上的取捨 — DAX 換 latency 的代價是放棄 strong consistency。read-your-write 嚴格場景不能靠 DAX。

query cache stale 的真實後果：

application 用 Query 列「某 user 的 active order」、結果被 query cache 快取；user 新建一筆 order、item cache 更新了該筆 item、但 列表 query 的 cache 沒失效、user 重整頁面在 TTL 內看不到新訂單。修法不是調 DAX、是判斷「這個 query 能不能接受 TTL 內 stale」— 不能接受的、該 query 不要走 DAX（直接打 DynamoDB）、或縮短該類 query 的 TTL。

Scope warning：上述一致性語意屬 DAX vendor 規格 + 通用 cache 工程知識、非 production case 揭露；實際 staleness 視 cluster node 數、TTL 配置與讀寫分布而定。

操作流程

從 read pattern 評估到上線的 6 步流程。

Step 1：確認 read pattern 適配

在加 DAX 前、用 CloudWatch 看目標 table 的 read:write ratio 跟 read 的 key 重複度：

• read:write 高（讀遠多於寫）+ 重複讀同一組 key → 適合
• 寫密集 / 每次讀不同 key / 大量 strongly consistent read → 不適合（回頭看 gsi-lsi-design DAX 觸發條件）

Step 2：cluster sizing

1node 數 = 讀峰值 throughput / 單 node 容量 + 1（容錯餘量）
2node class = 依 working set 大小選（cache 要能裝下熱資料）

跨至少 2 個 AZ、確保 primary 故障有 replica 接手。

Step 3：application 切換 client

1import amazondax
2# 原本：dynamodb = boto3.resource("dynamodb")
3dax = amazondax.AmazonDaxClient.resource(endpoint_url="dax://my-cluster.xxx.dax-clusters.region.amazonaws.com")
4table = dax.Table("orders")
5# API 不變、讀寫自動經過 DAX
6response = table.get_item(Key={"PK": "ORDER#123", "SK": "META"})

Step 4：分流 strongly consistent read

1# 需要 strong 的讀直接走 DynamoDB、不要走 DAX
2ddb_table.get_item(Key=..., ConsistentRead=True)   # 繞過 cache
3# 可接受 eventual 的讀走 DAX
4dax_table.get_item(Key=...)                          # 走 cache

application 要明確區分哪些讀路徑能接受 stale、哪些不能；不能接受的不走 DAX。

Step 5：設定 TTL 與監控 hit rate

依資料變動頻率設 item / query cache TTL：變動慢的 metadata 可設長 TTL、變動快的設短或不快取。上線後盯 CacheHitRate。

Step 6：驗證點

1# 驗證 hit rate 達預期、確認 DAX 真的減少 DynamoDB 讀
2# CloudWatch: DAX CacheHits / (CacheHits + CacheMisses)
3# 同時看 DynamoDB ConsumedReadCapacityUnits 是否下降

Rollback boundary：DAX 可隨時 detach — application 端把 DAX endpoint 換回 DynamoDB endpoint 即可、無資料遷移；DAX 只是讀路徑加速層、不持有唯一資料。

失敗模式

production 常見的 5 個踩雷：

Case 1：把 DAX 當預設配置

寫密集 / 低 hit rate workload 加 DAX、invalidation 開銷 + cluster 成本 > cache 收益。修法：先確認 read pattern 適配（Step 1）、DAX 是讀峰值補位不是預設（觸發條件 SSoT 在 gsi-lsi-design）。

Case 2：以為 query cache 會即時反映寫入

寫入後列表 query 在 TTL 內看不到新資料、被當成 bug 長時間誤查。修法：理解 query cache 只靠 TTL 失效（不是 bug 是設計）；強一致列表需求的 query 不走 DAX、或縮短 TTL。

Case 3：strongly consistent read 全走 DAX 還抱怨不快

application 全程 ConsistentRead=True、DAX 全部 pass through、等於沒裝 DAX 還多付 cluster 錢。修法：分流 — strong read 直接打 DynamoDB、eventual read 才走 DAX。

Case 4：cluster 單 AZ / 單 node

省成本只開單 node、primary 故障時讀路徑整個失效、回退到 DynamoDB 瞬間流量尖峰。修法：跨 2+ AZ、primary + replica；DAX 故障的 fallback 路徑（直連 DynamoDB）要先測過。這個 Case 的失敗代價跟其他 Case 不對稱 — 其餘 Case 多是成本浪費或延遲沒降、detach DAX 即可回復；單 AZ / 單 node 故障是讀路徑硬中斷、回退瞬間把原本被 cache 吸收的讀峰值全打回 DynamoDB、若 base table 的 RCU 或 on-demand burst 餘量沒預留、會引發 throttling 連鎖。回退路徑要按「DAX 全失效時的讀峰值」預估 DynamoDB 側容量、而非平時被 cache 削減後的讀量。

Case 5：working set 超過 cache 容量

熱資料超過 node memory、cache 不斷 evict、hit rate 掉到沒意義。修法：依 working set 選 node class、或縮小快取範圍（只快取真正熱的 access pattern）。

Anti-recommendation：read:write ratio 低、或 cache hit rate 預期 < 50% 的 workload、不要上 DAX；application 端的 request-level cache 或根本不快取可能更划算。DAX 是 cluster 常駐成本（instance-hour 計）、只在讀峰值持續高才回本。

容量與觀測

CloudWatch metric：

• CacheHits / CacheMisses / 算出 CacheHitRate — 核心健康指標
• ItemCacheHits / QueryCacheHits — 分辨兩種快取各自的命中
• CPUUtilization / EvictedSize — node 是否過載、cache 是否頻繁 evict
• DynamoDB 端 ConsumedReadCapacityUnits — 確認 DAX 真的削減了 base 讀取

判讀：

• CacheHitRate < 70% — 重新評估 DAX 是否該存在、或快取範圍是否該收窄
• EvictedSize 持續高 — working set 超過 cache 容量、要加大 node class
• DynamoDB read capacity 沒因 DAX 下降 — read pattern 不適配、DAX 沒發揮作用

Scope warning：「70% hit rate 閾值」屬通用工程估算、非 case 揭露；實際閾值依 cost 結構與 latency 目標調整。

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

邊界與整合

DAX vs application-side cache vs ElastiCache

DAX 不是唯一的 DynamoDB 讀加速方案。三者責任不同：

• DAX：DynamoDB 專屬、API 相容、write-through、零 application cache 邏輯；綁 DynamoDB
• application-side cache（如 in-process LRU）：最低延遲、但每個 instance 各自一份、一致性難管
• ElastiCache（Redis / Valkey）：通用 cache、可跨資料源、但要自己寫 cache-aside 邏輯與 invalidation

當快取需求超出單一 DynamoDB table（跨資料源聚合 / 需要 Redis 資料結構如 sorted set leaderboard）、回 02 快取模組 評估 ElastiCache；DAX 最適配的情境是「純 DynamoDB 讀加速、且不想自行維護 cache 邏輯」。

Sibling 與 cross-link

• gsi-lsi-design — DAX 觸發條件 SSoT（讀峰值補位 / Lemino case fact / Capcom derive）在該篇、本篇承接機制層
• on-demand-vs-provisioned — DAX 削減 base 讀取後、provisioned RCU 規劃要重算
• consistency-model-optimization — strongly consistent read 繞過 DAX、對應 read 一致性軸
• partition-key-antipatterns — DAX 不解 hot partition、寫熱點仍打到 DynamoDB
• 替代路由：跨資料源快取 / Redis 資料結構需求 → 02 快取模組 ElastiCache
• 跟 Lemino 9.C29 互引：DAX 讀峰值補位的 case fact

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

訂單寫進 DynamoDB 後、搜尋索引要更新、快取要失效、要推一筆通知、要寫一筆 audit。第一版 application 在寫訂單的同一段 code 裡同步做完這四件事、結果單一步驟（推通知的外部 API）變慢、整個寫訂單路徑被拖垮。第二版改成「另一個 service 每 10 秒輪詢 table 撈新資料」、輪詢既貴（全表 scan）又慢（最差 10 秒延遲）。兩個痛點都指向同一個缺口 — 資料變更需要一條可靠、低延遲、不污染寫路徑的下游通道。這正是 DynamoDB Streams 的責任。本文展開 Streams 的 record 結構、順序保證的真實邊界、消費模式選擇與失敗處理。

事件機制前提：先確認 workload 適配 DynamoDB：事件驅動機制是已選 DynamoDB 後的議題；選型本身先過 workload 適配 4 軸 — PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定。判讀軸詳見 single-table-design-pattern 開頭 4 軸前置判讀。本文聚焦 已選 DynamoDB 後、把資料變更導向下游的事件機制。

核心機制：Stream record 與 view type

DynamoDB Streams 是 table 的 change data capture 通道 — 把 item 層級的 insert / modify / delete 變成一條時間排序的事件流。開啟後、每筆寫入產生一筆 stream record。

view type 決定 record 帶什麼：

view type 在開 stream 時定、改要重開 stream。選 NEW_AND_OLD_IMAGES 最方便但 record 最大（影響 Lambda payload 與成本）；下游只需 key 就回查的、選 KEYS_ONLY。

Scope warning：「stream record 保留 24 小時」、「Lambda 單次 batch 上限」這些屬 AWS vendor 規格、會隨版本調整、實作時 cross-verify 官方 doc。本文不含 production case 揭露的 stream 配置數字。

對應 knowledge card：change-data-capture、idempotency。

順序保證的真實邊界

這是 Streams 最常被誤解的點 — 「stream 是有序的」這句話只在特定範圍成立。

保證範圍：

• stream 切成多個 shard、每個 shard 對應 table 的一組 partition
• 同一 partition key 的所有變更、進同一個 shard、在 shard 內嚴格時間排序
• 跨 shard 沒有 全域順序保證

這代表：同一筆訂單（同 PK）的 create → update → delete 一定按序到下游；但訂單 A 跟訂單 B（不同 PK、可能不同 shard）的相對順序不保證。下游若依賴「跨實體的全域順序」、會踩雷。

shard split / merge：

table partition 會隨資料量與流量 split、stream shard 跟著變動。消費端要能處理 shard 生命週期（Lambda event source mapping 自動處理；自己用 SDK 拉的要處理 shard iterator 的 parent-child 關係）。

順序 + 冪等的組合：

Lambda 消費 stream 是 at-least-once — 同一筆 record 可能被送兩次（retry、shard 重平衡）。下游處理必須冪等：用 record 的 sequence number 或業務鍵去重、不能假設「每筆只處理一次」。每筆訊息帶獨立 message_id 的事件流天然適合 — message_id 當冪等鍵、重送不重複發。

Scope warning：上述順序與 at-least-once 語意屬 Streams vendor 規格 + 通用事件處理工程、非 production case 揭露。

消費模式：Lambda vs Kinesis

兩條主要消費路徑、責任與運維成本不同：

多數「寫入後觸發一個下游動作」用 Lambda event source mapping 最簡單。需要長 retention、多消費者 fan-out、或要重播歷史變更的、用 Kinesis Data Streams for DynamoDB。

Lambda event source mapping 的關鍵旋鈕：

• batch size：一次給 Lambda 幾筆 record（吞吐 vs 延遲）
• batch window：湊滿 batch 或等多久才觸發（低流量時的延遲控制）
• parallelization factor：一個 shard 並行幾個 Lambda（提升單 shard 吞吐、但犧牲 shard 內嚴格順序）

Scope warning：parallelization factor > 1 會在單 shard 內並行處理、放寬順序保證；需要嚴格順序的維持 factor = 1。具體上限屬 vendor 規格。

操作流程

從開 stream 到下游上線的 6 步流程。

Step 1：選 view type

依下游需要什麼決定。同步到搜尋索引要完整新 item → NEW_IMAGE；audit 要看改動 → NEW_AND_OLD_IMAGES；下游自己回查 → KEYS_ONLY。

Step 2：開 stream

1aws dynamodb update-table \
2  --table-name orders \
3  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

Step 3：接 Lambda event source mapping

 1def handler(event, context):
 2    for record in event["Records"]:
 3        event_name = record["eventName"]      # INSERT / MODIFY / REMOVE
 4        if event_name == "REMOVE":
 5            old = record["dynamodb"]["OldImage"]
 6            delete_from_search_index(old)
 7        else:
 8            new = record["dynamodb"]["NewImage"]
 9            upsert_to_search_index(new)
10        # 冪等：用 sequence number 或業務鍵去重
11        seq = record["dynamodb"]["SequenceNumber"]

Step 4：設定 batch 與失敗處理

1BatchSize: 依下游處理能力與延遲目標
2MaximumBatchingWindowInSeconds: 低流量湊批、控制延遲
3BisectBatchOnFunctionError: true   # 失敗時二分批、隔離壞 record
4MaximumRetryAttempts: 有限次       # 避免毒丸 record 無限重試
5DestinationConfig.OnFailure: DLQ   # 超過重試送 DLQ

Step 5：下游冪等設計

下游 upsert 用業務鍵（PK）做 idempotent write、刪除用「刪不存在不報錯」；確保同一 record 處理兩次結果相同。

Step 6：驗證點

1# 灌一筆寫入、確認下游在預期延遲內收到對應 record
2# CloudWatch: Lambda IteratorAge（消費落後程度）應接近 0
3# 製造一筆會失敗的 record、確認進 DLQ 而非卡住整個 shard

Rollback boundary：關 stream 即停止產生新 record；已產生的 record 在 retention 內仍存在。下游邏輯出錯時、修好 Lambda 後可在 retention 內讓未處理 record 重新消費（或從 DLQ 重放）。

失敗模式

production 常見的 5 個踩雷：

Case 1：下游非冪等、重送導致重複副作用

at-least-once 重送、下游每次都發一筆通知、用戶收到重複推播。修法：下游用業務鍵冪等、sequence number 去重；副作用（發通知 / 扣款）必須 idempotent。

Case 2：依賴跨實體全域順序

下游假設「所有訂單事件按全域時間到達」、實際跨 shard 無此保證、算錯聚合。修法：只依賴「同 PK 內有序」；需要跨實體順序的、在下游用 event timestamp 重排、或重新設計不依賴全域順序。

Case 3：毒丸 record 卡住整個 shard

某筆 record 讓 Lambda 永遠拋例外、預設行為是重試整個 batch、shard 卡死、IteratorAge 無限上升。修法：開 BisectBatchOnFunctionError + MaximumRetryAttempts + DLQ、隔離壞 record 讓其餘繼續。

Case 4：consumer 落後、record 過期遺失

下游處理太慢、IteratorAge 超過 stream retention、未處理 record 被清掉。這個 Case 的代價跟前三個不同層級：前三個是「重複副作用 / 算錯聚合 / shard 卡住」、都還在 stream 裡留有 record、修好邏輯後可重新消費或從 DLQ 重放。Case 4 是 record 本身已被 retention 清除、那段時間的資料變更在 stream 這條通道上永久消失、沒有回退路徑。要補回只能反向比對 table 當前狀態跟下游狀態（若下游存得了），或在源頭重跑一次寫入觸發新 record — 兩者都是事故後的人工修復、成本遠高於前三個 Case 的設定旋鈕。

因為不可逆、防線要前置在「逼近 retention 之前」而非「過期之後」：IteratorAge alarm 的閾值設在遠低於 retention 的水位、留出擴容反應時間；吞吐不足時加 parallelization factor 或改 Kinesis（更長 retention、爭取更大的落後緩衝）；下游設計要能水平擴、讓落後可被快速追平。

Case 5：parallelization factor 開了還抱怨順序錯

為提吞吐把 factor 開 > 1、又依賴 shard 內嚴格順序、兩者矛盾。修法：需要嚴格順序維持 factor = 1；要並行吞吐就接受順序放寬、或把順序敏感的處理移到下游用 PK 分組。

Anti-recommendation：只有單一同步下游、且寫路徑延遲容忍度高 → 直接在 application 寫入後同步處理可能更簡單、不必引入 stream 的運維與冪等複雜度。Streams 的價值在「多下游 / 解耦寫路徑 / 低延遲 CDC」。

容量與觀測

CloudWatch metric：

• IteratorAge（Lambda）：消費落後程度、最關鍵指標、持續上升代表下游跟不上
• Lambda Errors / Throttles：下游處理失敗 / 被限流
• DLQ 訊息數：毒丸 record 累積、需要人工介入
• stream ReadProvisionedThroughputExceeded（Kinesis 模式）：消費端讀超限

判讀：

• IteratorAge 接近 retention 上限 → 資料變更即將遺失、緊急擴消費端
• DLQ 持續累積 → 有系統性壞 record、查 Lambda 邏輯或上游資料
• Errors 尖峰但 IteratorAge 正常 → transient 失敗、retry 有在吸收

Scope warning：本文未引用 production case 的 stream metric 數字；上述指標與判讀屬 vendor 規格 + 通用事件處理觀測。

接回 4.20 Observability Evidence Package、9.5 瓶頸定位流程。

邊界與整合

Streams 跟 03 訊息佇列的責任切分

DynamoDB Streams 是 資料庫變更 的 CDC 通道、不是通用訊息佇列。兩者責任不同：

• Streams：源頭是 table 寫入、record 由 DynamoDB 自動產生、生命週期綁 table、retention 短
• 訊息佇列（SQS / SNS / Kafka）：源頭是 application 主動 publish、用於通用解耦、retention 與語意更彈性

典型組合：Streams 捕捉 table 變更 → Lambda 處理 → 需要扇出到多個獨立服務時、再 publish 到 SNS / EventBridge。當事件來源不是「資料庫變更」而是「業務事件」、直接用 03 訊息佇列模組 的 queue / topic、不要硬塞進 table 再用 stream。

Sibling 與 cross-link

• transactions-conditional-writes — transaction 寫入也觸發 stream、下游處理要冪等
• single-table-design-pattern — single-table 下不同 entity 共用 stream、下游用 type 欄位分流
• global-tables-conflict — Global Tables 跨 region 複製本身基於 stream 機制
• 替代路由：通用業務事件 / 多消費者扇出 / 長 retention → 03 訊息佇列模組
• 搜尋索引同步下游 → OpenSearch / Elasticsearch（DynamoDB 不適合做全文檢索）
• 跟 PayPay 9.C26 互引：訊息事件 message_id 天然冪等、適合 stream 下游處理

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

訊息系統的 storage bill 每月穩定上漲、查 table 發現裡面堆了三年份的過期通知、沒人清。team 設了 TTL「自動清理」、結果兩個新問題冒出來：第一、設了 TTL 之後 storage 還是沒馬上降、過了好幾小時才開始掉；第二、有個報表 query 把「已過期但還沒被刪」的 item 也撈進來、算錯數字。兩個痛點揭露 DynamoDB TTL 的真實語意 — 它是 最終會刪除 的背景機制、不是即時刪除、也不是查詢層的過濾器。本文展開 TTL 的 epoch 語意、刪除延遲特性、過期可讀陷阱與 storage 成本判讀。

生命週期前提：先確認 workload 適配 DynamoDB：資料生命週期管理是 已選 DynamoDB 之後才浮現的議題 — TTL 解的是「資料存進來之後怎麼自動退場」、而非「資料該不該存進 DynamoDB」。後者由 4 軸前置判讀決定：PK 天然均勻 / control plane vs data plane / consistency 可接受 eventual / access pattern 穩定、判讀軸詳見 single-table-design-pattern 開頭 4 軸前置判讀。本文承接該前提、聚焦用 TTL 管理資料生命週期與 storage 成本。

核心機制：TTL attribute 與背景刪除

DynamoDB TTL 讓 item 在指定時間後自動被刪除、不消耗寫容量。機制很簡單但語意有三個容易踩的邊界。

設定方式：在 item 上放一個數值 attribute、值是 Unix epoch 秒數（不是毫秒、不是 ISO 字串）、並在 table 啟用 TTL 指向該 attribute：

1import time
2table.put_item(Item={
3    "PK": f"MSG#{msg_id}",
4    "SK": "META",
5    "body": "...",
6    "expireAt": int(time.time()) + 30 * 86400,  # 30 天後過期、epoch 秒
7})

三個關鍵語意：

第二列是報表算錯的根因：TTL 不是查詢過濾器。過期到實際刪除之間有一段窗口、這期間 item 還在、還會被讀到。需要「過期立刻不可見」的、application 必須在讀取後自己比對 expireAt 過濾。

Scope warning：「TTL 通常 48 小時內刪除」屬 AWS vendor 規格描述、AWS 不保證準時、實際延遲視 table 大小與背景負載而定、實作時 cross-verify 官方 doc。9.C26 PayPay case 揭露「TTL 機制可自動清理過期訊息」的 用途、未揭露刪除延遲的具體數字。

對應 knowledge card：ttl、soft-ttl。

刪除延遲與過期可讀：兩個必須處理的窗口

TTL 的「最終刪除」特性製造兩個 application 必須意識的窗口。

窗口一：過期 → 實際刪除（可讀窗口）：

item 的 expireAt 已過、但背景程序還沒刪。這段時間 item：

• 仍會被 Query / Scan / GetItem 撈到
• 仍佔 storage、仍計 storage 費
• 仍會被 secondary index 索引到

application 若依賴「過期就消失」、會在這個窗口讀到 stale 資料。正確做法是 read 後 filter：

1import time
2now = int(time.time())
3items = [it for it in response["Items"] if it.get("expireAt", 1 << 62) > now]

或在 query 加 FilterExpression 排除過期 item（注意 filter 在讀取後套用、仍消耗讀容量）。

窗口二：TTL 刪除 → stream record：

TTL 刪除會在 stream 產生一筆 REMOVE record、且 userIdentity 標記為 DynamoDB 服務本身（principal dynamodb.amazonaws.com）。這讓「過期歸檔」成為可能 — 下游 Lambda 收到 TTL 刪除事件、把 item 寫進冷儲存（S3）再讓它從 hot table 消失：

1def handler(event, context):
2    for record in event["Records"]:
3        if record["eventName"] == "REMOVE":
4            principal = record.get("userIdentity", {}).get("principalId")
5            if principal == "dynamodb.amazonaws.com":  # TTL 刪除、非 application 刪除
6                archive_to_s3(record["dynamodb"]["OldImage"])

區分「TTL 自動刪除」vs「application 主動刪除」靠 userIdentity — 兩者都是 REMOVE record、但只有 TTL 刪除帶服務 principal。對應 streams-lambda-event-driven。

Scope warning：stream record 的 userIdentity 標記屬 vendor 規格、欄位細節 cross-verify 官方 doc；本段機制描述非 production case 揭露。

操作流程

從生命週期需求到上線的 6 步流程。

Step 1：判斷資料是否適合 TTL 管理

適合 TTL 的資料有「自然過期時間」：session、訊息通知、暫存 token、event log、合規保留期到期的資料。不適合的：需要精確即時刪除的、需要刪除前審批的、永久保存的。

Step 2：設計 expireAt 計算

寫入時算好 epoch 秒數的 expireAt；不同資料類型可不同保留期（通知 30 天、session 1 天、audit 依合規要求）。

Step 3：啟用 table TTL

1aws dynamodb update-time-to-live \
2  --table-name messages \
3  --time-to-live-specification "Enabled=true, AttributeName=expireAt"

Step 4：read 路徑加過期過濾

所有面向用戶的讀取、在 application 端比對 expireAt（或加 FilterExpression）；不要假設過期 item 已消失。

Step 5：（可選）接 TTL 刪除歸檔

需要保留過期資料的、接 stream Lambda、用 userIdentity 辨識 TTL 刪除、歸檔到 S3。

Step 6：驗證點

1# 寫一筆短 TTL item、等過期後確認：
2# 1. 過期但未刪窗口內仍可讀到（驗證需要 filter）
3# 2. 數小時後背景刪除生效、storage 下降
4# 3. 若接歸檔、確認 S3 收到對應 OldImage

Rollback boundary：關閉 TTL 即停止自動刪除、已刪除的 item 不可恢復（除非有歸檔）；啟用 TTL 前先確認 expireAt 計算正確、避免誤設過短把活躍資料刪掉。

失敗模式

production 常見的 5 個踩雷：

Case 1：expireAt 用毫秒或 ISO 字串

TTL 只認 Unix epoch 秒；填毫秒（多三位數）會讓過期時間落在遙遠未來、item 永不過期；填字串 TTL 直接不生效。修法：統一用 int(time.time()) + seconds、寫測試驗證 attribute 是秒級數值。

Case 2：以為 TTL 是即時刪除、做即時失效邏輯

用 TTL 當「到點立刻不可用」的開關（如優惠券到期）、實際過期後幾小時還能用。修法：即時失效靠 application 邏輯比對時間、TTL 只負責 清理 storage、兩者分開。

Case 3：報表 / 對帳撈到過期未刪 item

聚合 query 沒過濾過期 item、把可讀窗口內的殘留資料算進去。修法：所有讀取路徑一致地過濾 expireAt；對帳查詢明確排除過期。

Case 4：誤設過短保留期刪掉活躍資料

這個 case 跟前三個的失敗代價層級不同。前面的踩雷多半可回復 — storage 緩漲可回填、過期未刪可在讀取路徑加 filter、index 殘留會隨背景刪除自然消退。誤設過短保留期則是 不可逆 的：expireAt 計算 bug（少乘 86400、用錯時區基準）把保留期算成幾小時、背景程序把仍在使用的活躍資料當成過期 item 刪除、而 TTL 刪除不寫 undo log、刪掉就沒有從 DynamoDB 端救回的途徑、只能靠外部備份（PITR / 另存的 stream archive）回灌、且回灌期間資料缺口已經對線上服務造成影響。

代價的關鍵在於計算錯誤的爆炸半徑：一個錯誤常數會同時套用到所有新寫入 item、刪除是持續發生的背景行為、發現時往往已刪掉大批資料。修法的重心因此放在 上線前驗證 而非事後補救：上線前在 staging 用短週期資料驗證 expireAt 算出的絕對時間點符合預期、TTL 啟用初期把 TimeToLiveDeletedItemCount 跟預估刪除量對照、刪除量明顯偏高就立即停用 TTL 並排查計算、不等 storage 趨勢確認。對保留期敏感的 table 先開 PITR 當不可逆操作的最後防線。

Case 5：過期 item 仍被 GSI 索引、推高 index 成本

過期未刪 item 仍佔 GSI storage；大量過期堆積時 GSI 成本沒因「邏輯過期」下降。修法：理解 GSI 跟著 base item 生命週期、storage 降要等實際刪除；對成本敏感的 sparse index 設計可讓過期 item 不進 GSI（對應 gsi-lsi-design sparse index）。

Anti-recommendation：資料量小、storage 成本可忽略、或刪除需要審批/合規記錄 → 不必用 TTL；手動或排程刪除更可控。TTL 的價值在「大量有自然過期時間的資料、要低成本自動清理」（如 PayPay 式每日上億訊息）。

容量與觀測

CloudWatch metric：

• TimeToLiveDeletedItemCount：TTL 背景刪除的 item 數、確認 TTL 真的在運作
• table ItemCount / storage size：長期趨勢、確認過期清理讓 storage 趨於穩態
• 過期未刪比例：自行用 expireAt < now 的 item 數估算可讀窗口殘留量

判讀：

• TimeToLiveDeletedItemCount 為零但有設過期資料 → TTL 沒生效（attribute 名稱錯 / 值格式錯）
• storage 持續上漲且 TTL 刪除量遠小於寫入量 → 保留期設太長、或寫入遠超過期速度、要重估保留策略
• 大量過期未刪堆積 → 背景刪除跟不上寫入、storage 成本被殘留拉高

Scope warning：9.C26 PayPay 的「3 億/天 × 30 天 = 90 億筆」是 PayPay case 文章（9.C26）的策略段推算、非 PayPay 官方揭露的精確 item 數；引用時當量級壓力 anchor、不當精確數字。

接回 9.6 容量規劃模型、1.10 KV / Document DB 容量規劃。

邊界與整合

TTL vs cache TTL vs 合規保留

「TTL」這個詞在不同層意義不同、不要混用：

• DynamoDB TTL：主資料的生命週期管理、最終刪除、本篇主寫
• cache TTL（如 DAX item / query cache、Redis TTL）：快取副本的新鮮度邊界、過期是「重新回源」不是「刪除主資料」、主寫於 02 快取模組 與 dax-caching-strategy
• 合規保留期：法規要求的最短/最長保存、可用 TTL 實作到期清理、但刪除前的稽核記錄要另外保留（對應 7.7 audit trail）

Sibling 與 cross-link

• streams-lambda-event-driven — TTL 刪除觸發 stream REMOVE record、用 userIdentity 辨識、可做過期歸檔
• single-table-design-pattern — single-table 下不同 entity 用不同 expireAt 保留期
• gsi-lsi-design — 過期未刪 item 仍佔 GSI、sparse index 可讓過期不進 GSI
• on-demand-vs-provisioned — TTL 刪除免 WCU、不影響寫容量規劃、但 storage 成本要靠 TTL 控制
• 替代路由：快取副本新鮮度 → 02 快取模組；合規稽核 → 7.7 audit trail
• 跟 PayPay 9.C26 互引：每日上億訊息用 TTL 自動清理避免 storage 爆炸的 case anchor

本文是 DynamoDB overview 的 migration playbook。寫作參照 Migration Playbook 寫作方法論。

「我們要把 RDS 整個搬到 DynamoDB。」這句話本身就藏著最大的誤解 — DynamoDB 遷移不是把 table schema 1:1 搬過去。RDS 的 normalized schema、JOIN、ad-hoc query 在 DynamoDB 沒有對應物；MongoDB 的彈性 document、二級索引、aggregation pipeline 也不能直接映射。字面意義的「遷移」不成立 — 遷移的動作是 從 access pattern 重新設計資料模型、搬資料只是最後一步。能不能遷、該遷多少，取決於 workload 的查詢形狀是否固定、一致性需求是否能放寬。本文走 paradigm shift 結構：先講為何字面遷移不成立、再講哪些該遷哪些該留、最後才是階段化執行。

6 維 diff audit：主導維度是 paradigm

遷移前先盤點 source 跟 target 的差異落在哪幾維、決定 playbook 結構：

主導維度是 paradigm（其次 schema / application change）。這定義了結構 — Type E paradigm shift（排除 schema 翻譯 Type A 和 drop-in Type B）：部分遷移、長期混合架構、不收斂到「全部搬完」。

No-go condition：workload 需要 ad-hoc 分析查詢、跨實體 JOIN、頻繁 schema 變動下的彈性查詢、或複雜多表交易 → 不該遷 DynamoDB。這些是 relational / document 的主場、硬遷會把複雜度推給 application 層（自己做 JOIN、自己維護冗餘）。

為什麼字面遷移不成立：paradigm gap

RDS / MongoDB 是 先有資料模型、再支援任意查詢；DynamoDB 是 先有查詢、才設計資料模型。這個順序顛倒是遷移的核心難點。

relational → DynamoDB 的斷層：

• JOIN 消失：relational 用 JOIN 組合多表、DynamoDB 要嘛預先反正規化（把關聯資料寫在同一 item / 同一 partition）、要嘛 application 多次查詢自己組
• ad-hoc query 消失：RDS 可以對任意欄位下 WHERE、DynamoDB 只能用 PK/SK 或預建 GSI 查（對應 gsi-lsi-design）
• 強一致交易縮窄：relational 任意多表交易 → DynamoDB 有限的 TransactWriteItems（對應 transactions-conditional-writes）

document（MongoDB）→ DynamoDB 的斷層：

• 看似接近（都是 NoSQL / document-ish）、實際 MongoDB 的二級索引彈性、aggregation pipeline、彈性 query 在 DynamoDB 都沒有對應
• MongoDB 可以「先存進去、之後再想怎麼查」；DynamoDB 不行、access pattern 沒想清楚就建表、後面要重做

所以遷移的第一步不是匯資料、是 窮舉 access pattern：列出 application 對這份資料的所有讀寫路徑、每條路徑對應 DynamoDB 的 PK/SK/GSI 設計。access pattern 列不完整、就還不能開始遷。

哪些 workload 該遷、哪些該留（混合架構）

Type E 的本質是 不收斂 — 不是所有資料都該進 DynamoDB、混合架構會長期存在。判讀標準：

9.C20 Zomato 是這個判讀的 case anchor：Zomato 遷的是 billing platform（帳單事件、access pattern 固定、可接受 eventually consistent）、不是把整家公司的資料庫都搬。帳單系統從 TiDB 遷到 DynamoDB 後吞吐 2,000 → 8,000 RPM（4x）、延遲降 90%、成本降 50%；動機是 TiDB 必須為突發流量峰值預先 over-provision、DynamoDB on-demand「pay only for what we use」避免常態浪費。

Scope warning：Zomato 的「成本降 50%」是 當下流量 下的對照、不是永久結論；「延遲降 90%」可能主要是 p50、p99/p999 改善幅度通常較小。這兩點 case 原文已標明、引用時不可升級成「DynamoDB 永遠更便宜更快」。crossover 判讀見下方容量段。

Phase plan：access-pattern-first 階段化

paradigm shift 的階段化把不可逆動作放到最後、每階段有獨立驗證門檻：

Phase 1：access pattern 窮舉

列出 application 對目標資料的所有讀寫路徑、標每條的頻率、一致性需求、是否可放寬。這份清單是後續所有設計的輸入、不完整不進下一階段。

Phase 2：DynamoDB 資料建模

依 access pattern 設計 PK/SK、single-table 結構、需要的 GSI、capacity mode。對應 single-table-design-pattern、partition-key-antipatterns。

Phase 3：dual-write

application 同時寫舊（RDS / MongoDB）跟新（DynamoDB）。舊系統仍是 source of truth、DynamoDB 累積資料。dual-write 要處理寫入失敗一致性（其中一邊失敗如何補償）。

Phase 4：backfill 歷史資料

把舊系統既有資料按新模型轉換寫入 DynamoDB。backfill 跟 dual-write 並行時要處理覆蓋順序（backfill 不能覆蓋掉 dual-write 的新值）。

Phase 5：shadow read 驗證

讀路徑同時打舊跟新、比對結果、記錄差異但仍以舊系統回應用戶。shadow read 是 cutover 前的信心來源 — 差異率降到可接受才進 cutover。對應 1.7 Schema Migration Rollout 證據 的 evidence 方法。

Phase 6：漸進 cutover

讀流量逐步從舊切到新（按比例 / 按 user segment）、保留隨時切回的能力。cutover 完成後 DynamoDB 成為該 workload 的 source of truth；但其他未遷 workload 仍在 RDS / MongoDB — 混合架構成立。

Evidence：每階段的前進依據

每個階段用資料證明可前進、不靠感覺：

這些 evidence 對齊 4.20 Observability Evidence Package（Source / Time range / Query link / Owner / Data quality）與 6.8 release gate 的 gate 決策。

Cutover 與 rollback 決策

資料庫切流失敗代價高、決策權責要寫清楚：

• cutover window：選低流量時段、明確切流比例階梯（如 1% → 10% → 50% → 100%）
• rollback condition：新系統 error rate / latency 超過閾值、或 shadow read 差異率異常 → 切回舊系統
• decision owner：誰有權喊停、依據什麼 evidence、記錄在 8.19 incident decision log（Timestamp / Decision / Context / Evidence / Owner / Rollback condition）
• 資料凍結策略：cutover 期間若需要凍結寫入、明確凍結範圍與時長

對應 rollback window、rollback condition。

Cleanup 與長期混合

Type E 的 cleanup 不一定是「退役舊系統」— 多數情況舊系統仍服務未遷 workload：

• 已遷 workload 的舊 schema / 舊 writer / dual-write code path 退役
• shadow read 比對 code 移除
• 但 RDS / MongoDB 本身保留（服務 analytics / 強一致 / 彈性查詢 workload）
• 明確標示哪條資料路徑的 source of truth 是 DynamoDB、哪條仍是 RDS / MongoDB、避免「到底哪個是真的」混亂

混合架構不是過渡失敗、是 paradigm shift 的穩態 — 每個 workload 待在最適合它的儲存層。

失敗模式

production 常見的 5 個踩雷：

Case 1：先匯資料才想 access pattern

把 RDS table 結構直接搬成 DynamoDB item、上線後發現查不出要的資料、要重建表。修法：access pattern 窮舉是 Phase 1、資料建模是 Phase 2；順序不能顛倒。

Case 2：把 JOIN 邏輯推給 application 卻沒評估成本

遷了關聯資料、application 每次查詢做 N 次 DynamoDB 呼叫自己組 JOIN、latency 跟成本爆炸。修法：關聯資料在建模階段反正規化（同 partition / 同 item）；無法反正規化的關聯查詢、該 workload 可能不適合遷。

Case 3：dual-write 一邊失敗沒補償

dual-write 時 DynamoDB 寫成功 RDS 失敗（或反之）、兩邊資料分歧、cutover 後發現新系統資料不完整。修法：dual-write 要有失敗補償（記錄失敗、重試、或標記該筆需人工對帳）；對應 1.9 Reconciliation 與 Data Repair。

Case 4：跳過 shadow read 直接 cutover

對自己的建模有信心、省掉 shadow read、cutover 後才發現 access pattern 漏了某個查詢路徑、生產出錯。修法：shadow read 是 cutover 前唯一能在真實流量下驗證新模型的階段、不能省。

Case 5：只看當下成本忽略 crossover

遷移時算出成本降 50% 就下決策、未來流量成長後 DynamoDB cost-per-request 累積超過自管 cluster、反而更貴。修法：算 12-24 個月在預期流量下的成本曲線、不是當下 snapshot（見容量段）。

Anti-recommendation：workload 查詢需求還在快速變化、或團隊對 access-pattern-first 建模沒經驗 → 先不要遷；用一個低風險、access pattern 已穩定的 workload 試點（如 Zomato 的 billing platform）、累積經驗再擴大。

容量與成本：crossover 判讀

DynamoDB 成本判讀的關鍵是 未來流量曲線、不是遷移當下的 snapshot：

• 遷移當下：相對 over-provisioned 的自管 cluster、DynamoDB on-demand 常更便宜（Zomato -50%）
• 流量成長後：DynamoDB cost-per-request 隨用量線性成長、自管 cluster 在高且可預測流量下有 crossover 點、可能反超便宜
• 判讀分層：小/中流量或流量不可預測 → DynamoDB 划算；大且可預測流量 + 已有 DBA 團隊 → 算自管 crossover

這條 vendor-level 成本軸主寫於 on-demand-vs-provisioned 軸 6；本篇從遷移決策角度引用、不重複展開 6 軸。

Scope warning：crossover 點隨 region pricing、workload shape、團隊成本結構變動、無通用閾值；Zomato 的具體百分比是單一 case 當下對照、不可外推。

接回 9.7 成本邊界與 efficiency、1.10 KV / Document DB 容量規劃。

邊界與整合

跟其他遷移路徑的關係

• DynamoDB → SQL / search / analytics split（遷出方向）：當 DynamoDB workload 長出 ad-hoc 查詢需求、把分析部分拆到 OpenSearch / 數倉、是反向路徑、屬另一篇 playbook scope
• MongoDB → Atlas：若只是要 managed MongoDB 而非換 paradigm、走 MongoDB → Atlas、不必遷 DynamoDB（保留 document paradigm）
• 跨平台等效：RDS → Aurora（保留 relational）、MongoDB → Cosmos DB（保留 document）、都比遷 DynamoDB 的 paradigm 跨度小；先確認真的需要換 paradigm

Sibling 與 cross-link

• single-table-design-pattern — 遷移 Phase 2 資料建模的核心
• partition-key-antipatterns — 建模時 PK 均勻度判讀
• transactions-conditional-writes — 遷移後寫一致性如何在 DynamoDB 重建
• on-demand-vs-provisioned — cost crossover 軸 6 SSoT
• 1.6 資料庫轉換實作 — 通用 dual-write / shadow read / cutover 框架
• 跟 Zomato 9.C20 互引：billing platform 遷移的可量化對照與 cost crossover 警示