本文是 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 設計責任

本文不是 Cosmos DB overview（請看 Cosmos DB vendor 頁）— 而是 partition key 設計 + 故障演練的深度展開。Case anchor 是 9.C11 Minecraft Earth（synthetic partition key 強制分散、AR 遊戲玩家位置）+ 9.C21 ASOS（Black Friday 流量分散 + latency budget 拆解）。

Cosmos DB 適用度前置判讀：本篇假設 workload 已通過 Cosmos DB 適用度四層 framing（API model 三型遷移路徑 / RU 思維轉換成本 / multi-model 差異化是否真用上 / 跨雲 hedging vs 單雲 lock-in）— 詳見 mongodb-api-vs-sql-api 開頭四層 framing、本篇不重複展開。Partition key 設計是 已選 Cosmos DB 後 的硬約束議題；若 workload 不適用 Cosmos DB、partition key 設計無法救回 vendor 選錯的不可逆性風險。

問題情境

典型觸發場景：團隊用 user_id 當 partition key 上 production、平常正常、Black Friday 或 VIP 大客戶上線當天 — application 收到 429 TooManyRequests、p99 從 50ms 飆到 5s；查 portal Metrics 發現 整體 RU 使用率才 30% 但少數 partition 100% 滿、其他 partition 閒置。Cosmos DB 設了 10000 RU/s、實際只能用 2000 就 throttle。

讀者徵兆：

• 「Cosmos DB throughput 我設了 10000 RU、但寫入只有 2000 就 throttle」
• 「user_id 當 partition key 結果 VIP 用戶全卡在一個 partition」
• 「Hierarchical partition key 是 2023 後才有的、跟 composite 差在哪」
• 「partition key 選錯能改嗎」

真實壓力：

• 遊戲玩家位置（同伺服器集中同 partition、Minecraft Earth 場景）
• IoT 裝置遙測（單一裝置高頻寫入、device_id 不均）
• SaaS 多租戶（大客戶 vs 小客戶不均、tenant_id 直接當 partition key 會 hot）
• 零售商品 catalog（熱門 SKU vs 冷門 SKU 不均）

partition key 選錯的隱性成本：要改就是 export → recreate container with new partition key → import、無 in-place migration、production 等於停機窗口 + 全量資料搬移。selection 階段就要決定、不能 phase 後補。

核心機制

Partition 模型

每個 container 有 N 個 physical partition、每個 physical 上有多個 logical partition。同 partition key value 的所有 document 落到同一個 logical partition。Cosmos DB 動態調整 physical partition 數量（透明 split）、但 logical partition 的歸屬 永遠不變（同 PK value 永遠在同 logical）。

9.C11 Minecraft Earth 案例的平台特性段揭露「partition 動態分裂：透明」 — physical partition 的 split 對 application 透明、不需要 application 重連 / 重新 hash。但這個透明 只解 physical partition 容量 問題、不解 logical partition 熱點 — logical partition 由 PK value 決定、application 必須自己均勻散佈 value。

Logical partition 上限

10,000 RU/s + 20 GB storage、達 limit 後即使 container 還有總 RU、單一 partition key 一樣 throttle。這是 硬上限、不是 soft limit、不能調高。

20 GB storage 限制在小用戶通常碰不到、但對「以 tenant_id 為 PK 的大客戶」、storage 也可能先到上限（單一大客戶 50GB 資料、塞不進一個 logical partition）。

Partition key 設計三種模式

Synthetic（人工合成 key）

機制：用 {userId}_{random_0_to_99} 把單一 user 的寫入散到 100 個 logical partition。application 端 hash userId + random suffix、寫入時組合成 partition key。

副作用：read 需 fan-out 100 個 partition、單一 query RU 暴漲 100x。適合 write-heavy + 不需精準 read 場景（如 IoT telemetry、log）。

9.C11 Minecraft Earth 用 synthetic partition key 強制分散 — AR 遊戲玩家位置寫入頻繁、partition 分散讓單一玩家不會打爆一個 partition。但 case 沒揭露具體 schema、synthetic 細節屬 outline knowledge 推論。

Composite（多欄位合成）

機制：用 {tenantId}_{deviceId} 兩個欄位合成（Composite Partition Key 通用樣式）、避免單一 high-cardinality 欄位 hot。適合 多租戶 SaaS、單一 tenant 內又有多個 device、避免大 tenant 把所有寫入集中。

副作用：read 必須帶兩個欄位、否則 cross-partition query；query API 設計要強制帶 tenant + device。

Hierarchical（2023+ 原生支援）

機制：原生支援多層 key（最多 3 層、如 tenantId / deviceId / sessionId）、不用手動合成；query 可指定前綴做 partition scope query（如「拿 tenant X 的所有 device」單一 partition scope）。

適合：多層業務 hierarchy 場景（tenant → user → session、organization → team → project）。比 composite 優勢是 支援 prefix query、composite key 只能完整匹配。

1az cosmosdb sql container create \
2  --partition-key-paths "/tenantId" "/deviceId" \
3  --partition-key-kind "MultiHash" \
4  ...

設計順序要從 低 cardinality 到 高 cardinality（tenant 少、device 多、session 最多）— 反序會讓 prefix query 無意義。

跟其他 vendor 的可逆性對照（本章合成 frame）

跨 vendor 可逆性對照 SSoT：MongoDB / DynamoDB / Cosmos DB 三家 partition key 可逆性不在同一光譜（Cosmos DB 屬不可改、不可逆性最高）、跨 vendor 對照 SSoT 主寫位置在 DB3 entry — 三 vendor 對比 10 軸 + 對應的軸的延伸子段。本段聚焦 Cosmos DB 不可改特性對 selection 階段 access pattern audit 嚴格度的影響、不重複展開三 vendor 全光譜比較。

partition / shard key 的可逆性在 vendor 間差異懸殊：

對照表是本章合成 frame、9.C11 Minecraft Earth 沒直接揭露此對比、是從 outline knowledge 跟 MongoDB shard-key-selection 對照得出。引用時必須明示：Cosmos DB partition key 不可改是 設計選型的硬約束、不是「先選錯再改」可承擔的風險 — 這個約束直接決定 selection 階段的 partition key audit 嚴格度該多高。

對 selection 的意義：若團隊對 access pattern 不確定、不能用「先上 Cosmos DB 再說、不行再改」的心態、要先用 MongoDB / DynamoDB 試 access pattern、確定後再評估 Cosmos DB。

跟 DynamoDB partition key 對比

• DynamoDB：partition key + optional sort key、無 hierarchical key、adaptive capacity 自動補 hot partition（部分減緩、不完全解決）
• Cosmos DB：hierarchical key 是 原生功能、不靠 adaptive；單 logical partition 限制嚴格、必須前期設計

Cosmos DB 的 硬上限 + 不可逆性 跟 DynamoDB 的 adaptive + 可遷移 是兩種設計哲學 — selection 時要評估團隊能不能負擔前期 design effort。

對應 knowledge cards：hot-partition / database-sharding。

操作流程

設定 partition key

建 container 時指定、無法事後修改：

1az cosmosdb sql container create \
2  --account-name mycosmos --database-name mydb \
3  --name mycontainer --resource-group myrg \
4  --partition-key-path "/userId" \
5  --partition-key-version 2 \
6  --throughput 10000

Hierarchical key 設定（C# SDK 範例）

 1var properties = new ContainerProperties("mycontainer",
 2    new[] { "/tenantId", "/deviceId" });
 3properties.PartitionKeyDefinitionVersion = PartitionKeyDefinitionVersion.V2;
 4var container = await database.CreateContainerAsync(properties);
 5
 6// 寫入時帶完整 hierarchical key
 7var pk = new PartitionKeyBuilder()
 8    .Add("tenant-123")
 9    .Add("device-456")
10    .Build();
11await container.CreateItemAsync(item, pk);
12
13// Prefix query：拿 tenant-123 的所有 device
14var prefixPk = new PartitionKeyBuilder()
15    .Add("tenant-123")
16    .Build();
17var iterator = container.GetItemQueryIterator<Item>(
18    "SELECT * FROM c",
19    requestOptions: new QueryRequestOptions { PartitionKey = prefixPk });

Synthetic key 寫入

application 端 hash + random suffix、寫入時組合成 partition key：

 1import hashlib
 2import random
 3
 4def get_partition_key(user_id, fanout=100):
 5    suffix = random.randint(0, fanout - 1)
 6    return f"{user_id}_{suffix}"
 7
 8# Read 時 fan-out 所有可能 suffix
 9def read_user_data(user_id, fanout=100):
10    results = []
11    for suffix in range(fanout):
12        pk = f"{user_id}_{suffix}"
13        results.extend(query_partition(pk))
14    return results

注意 fanout 的 trade-off：fanout = 100 等於 read 成本 × 100；要在 write 分散 跟 read 效率 間平衡、通常 fanout 10-100 之間。

查 partition 分布

portal Metrics > Storage by partition key、看分布是否均勻；或用 SELECT * FROM c WHERE c.partitionKey = "specific-value" query + diagnostic log 看 RU 分布。

驗證點

• 每個 logical partition 的 RU 消耗 < 80% limit（給 burst 留 20% buffer）
• 單一 partition 的 storage < 16 GB（給成長預留 4 GB buffer）
• p99 latency 在 hot partition 不退化
• 跨 partition query 比例 < 5%（多數 query 帶 partition key 條件）

Rollback boundary

partition key 選錯只能 export → recreate container with new partition key → import；無 in-place migration、生產系統等於停機窗口 + dual-write cutover 流程。對應 1.12 大規模 DB 遷移實戰 的遷移模型。

失敗模式

Failure 1：user_id 直接當 partition key

高活躍用戶（VIP / bot / 大客戶）超過 10,000 RU/s、全 container 被 throttle；徵兆是 429 TooManyRequests 集中在少數 partition、整體 RU 利用率才 30%。

修：

• 短期：把 hot user 拉到獨立 container（合規上有時要這樣做、把 VIP / 企業客戶獨立治理）
• 長期：換 synthetic key（user_id + random suffix）或 composite key（tenant + user）
• selection 階段 audit：access pattern 是否會有「少數 user 主導流量」現象（B2B SaaS、VIP 用戶都有）

Failure 2：時間當 partition key

/createdDate 或 /yyyyMM、新資料全寫入最新 partition、舊 partition 冷掉浪費 — write hot + read 不均。徵兆：最新月份 partition throttle、其他月份 partition 閒置。

修：時間 + 業務維度組合（如 /yyyyMM-userId、/userId-yyyy）、避免純時間維度。time-series workload 該考慮 Azure Time Series Insights 或 Cosmos DB time-series 專屬模式。

Failure 3：Synthetic key 沒考慮 read 路徑

寫入散開但 read 必須 fan-out 100 partition、單一 query RU 暴漲 100x。徵兆：read 成本遠高於估算、RetrievedDocumentCount 跟 OutputDocumentCount 比例 > 50。

修：

• 用 Change Feed 把投影預先寫到 read-optimized container（partition key 用 user_id）、read 走投影
• 或調 fanout（10 而非 100）、平衡 write 分散跟 read 成本
• 或重新評估「真的需要 synthetic key 嗎」 — 多數場景用 composite 就夠

Failure 4：Hierarchical key 設計順序顛倒

把 high-cardinality 放第一層、prefix query 變得無意義。如 /userId/tenantId 而非 /tenantId/userId — 想拿「tenant X 的所有 user」變成 cross-partition query、完全失去 hierarchical 優勢。

修：設計順序從 低 cardinality 到 高 cardinality、跟業務 query pattern 對齊。建 container 前畫 access pattern 表、列每個 query 的 hierarchy 順序、再決定 partition key path。

Failure 5：不監控 partition 分布

partition skew 累積幾個月、直到事故才發現。production 上線初期 access pattern 還不明顯、半年後 VIP 客戶開始用、partition 失衡 — 來不及改 partition key、只能在 throttle 中應急。

修：上線第一天就設 alert：

• 單 partition RU 利用 > 80% 持續 5 min
• 單 partition storage > 16 GB
• 429 error rate 突增

每週看 portal Insights > Top contributors > Partition key range、early detect skew。

Failure 6：Container 之間 partition 設計不一致

跨 container query 需要 fan-out、cross-partition query 成本爆炸。常見 anti-pattern：訂單 container 用 user_id、商品 container 用 product_id、join 訂單 + 商品時兩邊都 cross-partition。

修：跨 container 的 access pattern 在 selection 階段就要設計、不能各 container 各自決定 partition key。或者用 Change Feed 把跨 container 資料合成 single container 的 materialized view。

容量與觀測

• 必看 metric：PhysicalPartitionThroughputInfo、NormalizedRUConsumption per partition、StorageDistributionPerPartition
• Hot partition 偵測：portal Insights > Top contributors > Partition key range
• 容量估算公式：peak RU per partition × partition 數 + 預留 buffer（一般 30%）= total RU/s
• 回 9.4 Saturation Discovery：把 partition skew 當 saturation signal
• Alert：單 partition RU 利用 > 80% 持續 5 min；429 error rate 突增

Latency budget 拆解：vendor SLA vs end-to-end 實測

9.C21 ASOS 觀察「48ms 平均響應 = 全球分散下 Cosmos DB 的代表性數字」段揭露：48ms 包含 網路 + DB + 應用層、DB 本身可能只佔 5-10ms、其他是網路與應用層。引用時不能把 vendor 廣告的 5-10ms p99 當「使用者體驗」、要明示「48ms 是 9.C21 ASOS 案例的 end-to-end 觀察、Cosmos DB 自身可能只佔 5-10ms（case 揭露的拆解推論、不是 case fact）」。

操作上要把 end-to-end latency 拆 budget：

• DB 端 latency（vendor SLA、p99 < 10ms 地區內讀、9.C11 揭露）
• 跨 region replication latency（multi-region read 從就近 region 拿、不會跨洲、但 cross-region write 不同、見 multi-region-write-conflict）
• 應用層 latency（serialize / business logic / HTTP overhead）
• 客戶端網路 latency（mobile / 跨洲）

跟 partition skew 的關係：partition 失衡時即使 vendor 端 SLA 達標、實測 p99 仍會被 hot partition 拉高 — 單一 partition 的 RU consumption 飽和 → 429 retry → 應用層 latency 暴漲 → end-to-end 從 48ms 變 500ms。partition 設計直接影響 end-to-end SLA 鏈路。

邊界與整合

• Sibling deep articles：ru-cost-model-sizing（partition skew 直接影響 RU sizing）、consistency-levels-engineering（partition 失衡時即使設 Strong 也看到 throttle）、multi-region-write-conflict（partition key 影響 conflict 分布）、mongodb-api-vs-sql-api（MongoDB shard key → Cosmos DB partition key 翻譯）
• 跟 DynamoDB vendor 對比：partition key + adaptive capacity vs 不可逆 + hierarchical
• 跟 MongoDB vendor 對比：reshardCollection 可逆 vs 不可逆
• 跟 1.x 章節：1.10 KV / Document DB 容量規劃 / 1.12 大規模 DB 遷移實戰
• Knowledge cards：Hot Partition / Database Sharding
• Anti-recommendation：小流量（< 1000 RU/s 預期）不必過度設計 synthetic key、Cosmos DB autoscale + 簡單 partition key 即可；過度 design 比 under-design 更常見的成本浪費

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 partition key design backlog 的深度展開
• 9.C11 Minecraft Earth case — synthetic partition key 主案例
• 9.C21 ASOS case — latency budget 拆解 + 全球零售流量分散
• Hot Partition 卡片 / Database Sharding 卡片 — 概念基底
• 官方：Cosmos DB partitioning / Hierarchical partition keys