觀察

Niantic Pokémon GO 在 GCP 上的關鍵敘述（引自 Bringing Pokémon GO to life on Google Cloud）：

關鍵敘述：「Niantic chose GKE for its ability to orchestrate container clusters at planetary-scale」「Google CRE seamlessly provisioned extra capacity on behalf of Niantic to stay ahead of their record-setting growth」。

判讀

這個案例最重要的判讀是「surge load 跟可預測峰值是不同問題」。

1. 50x surge 沒辦法事前規劃：任何合理的 capacity planning 都不會預留 50x headroom — 那會讓平日成本爆炸。surge 的工程做法不是「事前撐住」、是「事中快速補上」。對應 9.11 高峰事件準備 跟 08 事故處理模組 的事件管理。
2. CRE 不是技術、是 vendor 關係：Google Customer Reliability Engineering 是 GCP 提供給戰略客戶的 24/7 工程支援團隊。能即時為 Niantic 補容量靠的是 人 + 流程 + 工具 的組合、不是純技術。對應 00.6 操作控制服務選型 的廠商支援能力評估。
3. Kubernetes 是 surge 的前置條件：如果 Niantic 用 VM-based 架構、即使 CRE 想補容量也來不及 boot up。Container orchestrator 把 provisioning 時間從分鐘級降到秒級、才讓 surge 反應變得可能。對應 05 部署平台模組 的 platform 選型。

需要警惕：「Google CRE 即時補容量」這種敘述對中小客戶不適用。一般客戶在 surge 下能依賴的是 自己的 autoscaler、不是 vendor 工程師。設計 surge 對應策略時要假設「沒有 vendor 救援」。

策略

可重用的工程做法：

1. 接受 surge 不可避免、設計快速 onboard 流程：核心問題不是「會不會 surge」、是「surge 之後 24 小時內能不能撐住」。對應 9.11 高峰事件準備 跟 08.8 incident communication。
2. 降級機制作為 surge 救命稻草：當容量不足時、優先保住核心功能、暫時關閉非核心。對應 02.3 cache stampede 跟 01.6 high concurrency access 的降級設計。
3. 預先談好 vendor 緊急支援條款：戰略服務在簽約時就要談好 surge 期間的容量配額、限流豁免、CRE / TAM 支援、不要等出事才談。對應 00 服務選型模組 的 vendor relationship 設計。
4. container-first 是 surge 反應的前置：VM-based 架構在 surge 下擴容速度比 container 慢一個量級、會直接成為 bottleneck。

跨平台等效：AWS Enterprise Support + TAM、Azure Premier Support + CSAM 都有對等服務、但能即時動用工程師補容量的程度跟客戶等級綁定。

下一步路由

• 想對應 surge load → 9.11 高峰事件準備 + 08.6 incident severity trigger
• 想設計降級策略 → 01.6 high concurrency access + 02 快取模組
• 想評估 vendor 支援 → 00.6 operations control service selection
• 對照可預測峰值案例 → 9.C1 AWS Prime Day

引用源

• Bringing Pokémon GO to life on Google Cloud
• Google Customer Reliability Engineering

觀察

Minecraft Earth 在 Azure Cosmos DB 的關鍵敘述（引自 Minecraft Earth and Azure Cosmos DB）：

Cosmos DB 平台特性（引自 Cosmos DB technical overview）：

• 配置擴容延遲：99 百分位 5 秒內生效
• 多 model 支援：SQL API、MongoDB API、Cassandra API、Gremlin、Table
• partition 動態分裂：透明
• 5 個 well-defined consistency levels（strong / bounded staleness / session / consistent prefix / eventual）

判讀

Cosmos DB 設計揭露三個全球 KV / document DB 的容量設計重點。

1. 一致性是 spectrum、不是 binary：Cosmos DB 提供 5 個層級、每個延遲與吞吐特性不同。AR 遊戲的玩家位置不需要 strong consistency（位置稍微 stale 沒問題）、但庫存交易需要 strong。同一 application 內不同操作選不同 consistency、是進階的容量設計策略。對應 01.5 transaction boundary 的一致性取捨。
2. Request Unit (RU) 是抽象容量單位：1 RU = 1 KB document 的 strong read 成本、寫成本約 5 RU、複雜 query 可達數百 RU。容量規劃變成「估每個操作多少 RU × 操作頻率」、跟「估 CPU / IOPS」是不同的思維。對應 9.6 容量規劃模型 的容量單位設計。
3. turnkey global distribution = 容量單位的全球複製：開啟跨地區後、容量在每個地區都 mirror 一份、成本乘以地區數。對中等規模團隊、turnkey 省下大量 ops、但要算「全球複製的成本是否值得業務需求」。對應 9.7 成本邊界與 efficiency。

需要警惕：「100 萬 RU/s 通過測試」是 壓測通過、不是 生產持續跑。實際營運要看 partition key 設計是否均勻、是否有 hot partition、跨地區複製延遲是否符合業務需求。

策略

可重用的工程做法：

1. 一致性需求分流到不同 collection / table：同一 application 不同操作有不同一致性需求、用不同 collection 配不同 consistency level、不要一刀切。
2. partition key 設計影響容量上限：跟 DynamoDB 一樣、hot partition 會讓名義容量達不到。Cosmos DB 的特殊性是「synthetic partition key」可以混合多個 field 強制分散。對應 9.4 Saturation Discovery 的 hot partition 識別。
3. RU-based pricing 鼓勵 query 最佳化：每個 expensive query 都吃 RU、優化 query 直接降成本。對應 9.9 Performance Improvement Loop 的持續改進迴圈。

跨平台等效：AWS DynamoDB Global Tables（global KV）、GCP Spanner（global SQL with strong consistency）、ScyllaDB Cloud（自管 Cassandra）都是對等候選。差異是 multi-model 廣度（Cosmos 最廣）vs 一致性深度（Spanner 最強）。

下一步路由

• 想設計全球分散 KV → 01 資料庫模組 + 9.6 容量規劃模型
• 想對照強一致全球 OLTP → 9.C10 Spanner
• 想對照單區 KV 高吞吐 → 9.C5 Amazon Ads DynamoDB
• 想理解 consistency level 的取捨 → 01.5 transaction boundary
• 想理解 Cosmos DB 五層一致性的工程選擇 → Cosmos DB 一致性層次工程
• 想做全球 multi-region write 衝突收斂 → Cosmos DB 多 region write 衝突
• 想拆 partition key 設計與全球分散搭配 → Cosmos DB partition key 設計

引用源

• Minecraft Earth and Azure Cosmos DB part 2: Delivering turnkey geographic distribution
• A technical overview of Azure Cosmos DB
• Azure Cosmos DB: Pushing the frontier of globally distributed databases

觀察

Zoom 在 2020 年 COVID 期間的關鍵敘述（引自 DynamoDB Customers）：

關鍵敘述：「On the backend, they were able to manage this surge with Amazon DynamoDB for Zoom Meetings.」

判讀

Zoom surge 揭露三個 SaaS 突發成長的工程重點。

1. SaaS surge 是結構性、不是暫時性：Pokemon GO 上線爆紅後流量會隨熱度消退、Zoom COVID 成長是「永久 baseline 上移」。容量規劃不能假設「過幾個月會回來」、必須假設「3 億 DAU 是新常態」。對應 9.6 容量規劃模型 的長期 baseline 重新校準。
2. DynamoDB 「無限擴容」對 SaaS 元資料層特別適用：Zoom 會議 metadata（room ID、participant list、permission state）是典型 KV 工作負載、partition key（meeting_id）天然均勻、不會 hot partition。對應 9.C5 Amazon Ads 同樣的 partition 均勻優勢。
3. 媒體串流不在 DynamoDB：Zoom 的影音流量是 P2P + edge servers、不經 DynamoDB。DynamoDB 只承擔「control plane」、不承擔「data plane」。這個分離是擴 30 倍的前提 — 控制面跟資料面解耦、控制面用 managed 服務、資料面用專屬基礎設施。對應 9.5 瓶頸定位流程 的關鍵路徑切分。

需要警惕：「nearly infinitely」是行銷敘述、不是工程承諾。實務上 Zoom 在 COVID 初期確實遇到 outage 與性能問題、後續才穩定。讀案例時要看 最終狀態 跟 過程中的 incident。

策略

可重用的工程做法：

1. 控制面跟資料面分離：高頻 metadata 操作放 managed KV（DynamoDB / Cosmos DB / Firestore）、大資料量串流放專屬基礎設施（CDN / WebRTC / 自管 servers）。對應 05 部署平台模組 與 9.5 瓶頸定位流程。
2. surge 後重新校準 SLO baseline：30x 成長之後、SLO 的「正常範圍」要更新、否則 monitoring 會誤報。對應 9.12 SLO 與 Performance Budget 的 SLO 演進。
3. 長期 surge 觸發架構重新評估：DynamoDB 是「擴大量」的好選擇、但成本也跟著放大。當 baseline 從 1000 萬永久升到 3 億、原本的 on-demand 模式可能變得貴、要考慮 provisioned + auto-scaling 組合。對應 9.7 成本邊界與 efficiency。

跨平台等效：Google Meet 也用 Spanner / Firestore、Microsoft Teams 用 Cosmos DB — 三家視訊會議都靠 managed KV 撐 metadata、是同一個架構模式的不同 vendor 實作。

下一步路由

• 對照 product surge → 9.C8 Pokemon GO
• 想理解 control plane vs data plane → 9.5 瓶頸定位流程 + 05 部署平台模組
• 想規劃 surge 後的 SLO → 9.12 SLO 與 Performance Budget + 04.16 SLI / SLO 訊號
• 想評估 surge 下的 on-demand vs provisioned 切換 → DynamoDB on-demand vs provisioned
• 想避免 surge 觸發 hot partition → DynamoDB partition key 反模式

引用源

• Amazon DynamoDB Customers
• Zoom Video Communications on AWS