觀察

Amazon Ads 在 DynamoDB 的關鍵數字（引自 DynamoDB customers）：

讀寫比約 18:1。這個比例反映「曝光發生 1 次、後續查詢可能發生 18 次」的廣告計費邏輯。

判讀

這個案例最重要的不是「DynamoDB 能撐多少」、而是「為什麼可以這樣設計」。

1. 單表分散到上千個 partition：DynamoDB 把每個 table 拆成多個 partition、每個 partition 內部還可以再分散。9000 萬 reads / 秒 是上千個 partition 加總的結果、單一節點達不到這個量級。對應 9.5 瓶頸定位流程 的 sharding 邊界、跟 01 資料庫模組 的 partition 設計。
2. partition key 選擇直接決定容量上限：DynamoDB 的容量是「每 partition 上限 × partition 數量」。partition key 不均勻會出現 hot partition、實際容量遠低於名義容量。對應 9.4 Saturation Discovery 的 saturation 不一定是整體 saturation、而是 最熱的 partition saturation。
3. 99.999% availability ≈ 5 分鐘 / 年的容錯：廣告計費 1 分鐘斷線可能損失幾百萬美金廣告收入。這個 SLO 不是行銷數字、是真實的營收邊界。對應 04.16 SLI / SLO 訊號 與 9.12 SLO 與 Performance Budget。

需要警惕：「9000 萬 reads / 秒」這種敘述通常是 年度峰值的最高一秒、不是平均值。容量規劃要區分「最大瞬時」、「99 百分位平均」、「常態流量」三個不同口徑。

策略

可重用的工程做法：

1. partition key 設計是 KV 容量的第一決策：均勻分散、避免 hot partition、必要時加 random suffix 強制分散。對應 01 資料庫模組 的 schema design 章節。
2. read-heavy 跟 write-heavy 比例變化是容量警訊：當業務邏輯改變（例如新增即時報表）、讀寫比可能跳一個量級、原本的容量規劃會失效。對應 9.8 效能可觀測性 持續監控比例變化。
3. on-demand vs provisioned 是成本 vs 反應速度的取捨：on-demand 自動擴容但成本高、provisioned 便宜但需要預測。Amazon Ads 這種 sustained workload 通常用 provisioned + auto scaling、不用 on-demand。對應 9.7 成本邊界與 efficiency。

跨平台等效：GCP Cloud Bigtable + 良好 row key 設計、Azure Cosmos DB partition key 設計都是對等概念。差異是 DynamoDB 的 partition 透明度（你看不到 partition 數量）vs Bigtable 的明確 tablet 模型。

下一步路由

• 想規劃 KV 高吞吐架構 → 9.5 瓶頸定位流程 + 01 資料庫模組
• 想避免 hot partition → 01.6 高併發資料存取 + 9.4 Saturation Discovery
• 想對照其他 KV 案例 → 9.C11 Minecraft Earth Cosmos DB（Azure 全球分散）
• 想深入 DynamoDB hot partition 反模式 → DynamoDB partition key 反模式
• 想拆 access pattern 對應的 single-table design → DynamoDB single-table design
• 想評估 on-demand vs provisioned 切換時機 → DynamoDB on-demand vs provisioned

引用源

• Amazon DynamoDB Customers
• Handle traffic spikes with Amazon DynamoDB provisioned capacity
• Demystifying Amazon DynamoDB on-demand capacity mode

觀察

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

觀察

拓元 Tixcraft 在 AWS 的關鍵數字（引自 tixCraft Case Study 與 AWS re:Invent 2015 簡報）：

服務組合（依用戶提供的架構圖）：

• 入口：Amazon Route 53（DNS）+ CloudFront + S3（靜態資源 static.tixcraft.com）
• UI 層：Elastic Load Balancing → EC2 跨 3 個 Availability Zone（Tixcraft UI）
• API 層：ELB → EC2 跨 3 個 AZ（API）+ ElastiCache 加速 session
• 資料層：DynamoDB 作為主要寫入目標（接 UI 寫入跟 API 寫入）
• 付款層：獨立的 EC2 Payment、連到 traditional server（合作金流、跑於企業 data center）
• 同步層：S3 Sync + EC2 Bridge 跟 corporate data center 的 backend 雙向同步

判讀

拓元案例最值得讀的、是它揭露三個 flash-sale 工程設計的非直覺事實。

1. DynamoDB 作為寫入緩衝、不是 OLTP：搶票時的「訂單」先丟進 DynamoDB、傳統 server 用自己能承受的速度消費、即時生效在此架構下不是目標。架構上 DynamoDB 扮演 durable queue 的角色、不是傳統 OLTP DB。這層解耦讓「前端可以擴 130 倍、後端不用同步擴」、避免後端被前端拖垮。對應 03 訊息佇列模組 的 outbox / async delivery 概念、跟 01 資料庫模組 的 transaction boundary 分離。
2. DynamoDB IOPS 從 20 衝到 135,000 = partition 設計能撐：這個 6,750 倍的彈性不是 DynamoDB 魔法、是 partition key 設計均勻 的結果。partition key 不均、IOPS 上限是「最熱 partition 上限」、不是「總和」。對應 9.C5 Amazon Ads 的同一判讀重點、跟 9.4 Saturation Discovery 的 hot partition 識別。
3. 30 分鐘擴 130 倍 = 雲原生架構的存在證明：6 台 → 800 台不是手動操作、是 Auto Scaling Group + AMI prebuild + load balancer warmup 的組合。傳統 IDC 做不到。這層彈性是「30 秒內」flash-sale 的前置條件。對應 05 部署平台模組 的 autoscaling 與 9.6 容量規劃模型。

需要警惕的判讀盲點：

• 「限流到底怎麼做」這個工程社群關心的問題、架構圖上看不到明確元件。可能是「DynamoDB 寫入排隊 = 隱性限流」、也可能是 ELB / WAF / 應用層限流。沒有公開資訊不要過度推測。
• 2015 年的數字、用的還是 t2.micro 跟舊版 DynamoDB throughput model。現在等效實作可能會用 DynamoDB on-demand、AWS WAF、CloudFront WAF rules、或 SeatGeek-style Virtual Waiting Room（見 9.C16）。
• 「30,000 張 / 3 分鐘」是 票房成績、不是 系統極限。系統能撐遠不止這個量、只是票本身賣完了。

策略

可重用的工程做法：

1. flash-sale 的核心架構模式：寫入緩衝 + 慢速消費：前端把訂單塞進可彈性擴容的儲存（DynamoDB / Redis Stream / Kafka）、後端按自己能力消費。這個模式讓「短時間吸收洪峰」跟「實際處理」解耦。對應 03 訊息佇列模組 與 01 資料庫模組。
2. partition key 設計是 flash-sale 的命脈：搶票場景天然容易 hot partition（同一場演唱會 = 同一 event_id）、必須用 composite key（event_id + user_id_hash）或 write sharding（event_id + random_suffix）分散。對應 9.C5 Amazon Ads。
3. flash-sale 必須事先 ELB / Auto Scaling 預熱：開賣前 30-60 分鐘 pre-warm ELB、預先啟動最低額度的 EC2、避免 t=0 時冷啟動。對應 AWS 官方 Flash Sale 工程指引。
4. 付款層獨立、不被搶票流量影響：拓元把 Payment EC2 拉出來、直連傳統金流 server。讓「選位 + 下單」的高頻流量不會塞爆「付款」的低頻流量。對應 9.5 瓶頸定位流程 的關鍵路徑切分。
5. 限流（rate limiting）通常是隱性的、不一定看得到 component：DynamoDB 寫入排隊本身就是隱性限流；也可以加 WAF rate-based rule、ELB request throttling、或前置 Virtual Waiting Room 做明確限流（見 9.C16）。

跨平台等效：GCP Cloud Spanner / Bigtable + Cloud Pub/Sub 作 buffer + GKE autoscaling；Azure Cosmos DB + Service Bus + AKS；自建 PostgreSQL + Kafka + Kubernetes 都可以實作對等架構。差異是 vendor 整合度跟擴容速度。

下一步路由

• 想設計 flash-sale 緩衝架構 → 03 訊息佇列模組 + 01 資料庫模組 + 9.6 容量規劃模型
• 想做 partition key 設計 → 9.C5 Amazon Ads + 01.6 高併發資料存取
• 想做明確限流 / 排隊機制 → 9.C16 SeatGeek Virtual Waiting Room
• 想預熱 ELB / Auto Scaling → 05 部署平台模組 + 9.11 高峰事件準備
• 對照其他售票市場 → 9.C17 BookMyShow（印度市場、年售 2 億張）
• 想理解 flash-sale 場景的 partition key 反模式 → DynamoDB partition key 反模式
• 想評估 on-demand vs provisioned 在 flash-sale 的搭配 → DynamoDB on-demand vs provisioned

引用源

• tixCraft Case Study (AWS)
• tixCraft on AWS re:Invent 2015 Recap (SlideShare)
• tixCraft: Handling Millions of Ticketing Requests with AWS (YouTube)
• Top considerations for Flash sale events (AWS Cloud Operations Blog)
• Handle traffic spikes with Amazon DynamoDB provisioned capacity

觀察

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

觀察

Capcom 在 AWS 的關鍵敘述（引自 Capcom Case Study 與 DynamoDB Customers）：

關鍵敘述：「Capcom uses Amazon DynamoDB to meet this demand with single-digit millisecond response times」。

判讀

Capcom 案例揭露三個遊戲後端 KV 的工程重點。

1. 遊戲後端 KV = 跨遊戲共用基礎設施：Resident Evil / Street Fighter / Monster Hunter 是不同類型遊戲（單機+多人 / 對戰 / 合作打怪）、卻共用 同一套後端 KV。這個共用降低了單一遊戲的維運成本、也讓新遊戲上線時不用重做基礎設施。對應 05 部署平台模組 的 multi-tenant platform。
2. single-digit ms response time = 玩家體感「即時」的底線：戰鬥動作、技能釋放、玩家對戰都要次秒級反應、超過 10ms 就「卡」。這個延遲門檻反推 Capcom 必須用 sub-region cache（ElastiCache / 本地 game server）+ DynamoDB DAX、不能單靠 DynamoDB。對應 9.C3 Coinbase 的延遲反推。
3. 「工程資源從 DB 運維轉到遊戲品質」是 managed 服務的真實價值：Capcom 不是 IT 公司、是遊戲公司。把 DBA 時間從「Postgres patching、replication 設定、backup 排程」釋放到「遊戲機制設計、玩家行為分析」、才是 30% 成本下降的本質。對應 9.7 成本邊界與 efficiency 的人力成本工程化。

需要警惕：「billions of requests」沒指明時間單位（每秒、每天、每月）。讀案例時要找具體單位、不要直接套用到自家。

策略

可重用的工程做法：

1. 遊戲後端 KV 用 DynamoDB / Cosmos DB / Bigtable：partition key 用 player_id 天然均勻、不會 hot partition。對應 01 資料庫模組 的 schema 設計。
2. EKS 跑 game server、不直接連 DynamoDB：game server 處理遊戲邏輯（戰鬥、配對、防作弊）、DynamoDB 處理持久狀態。中間用 DAX 或 ElastiCache 減少 DynamoDB 呼叫。對應 9.5 瓶頸定位流程。
3. 多 IP / 多遊戲共用平台是降本核心：每個新遊戲不重做基礎設施、共用同一套 DynamoDB + EKS。跟 9.C12 Riot Games 的「single-tenant per game」對照 — 不同 IP 公司有不同取捨。

跨平台等效：GCP Bigtable + GKE + Memorystore、Azure Cosmos DB + AKS + Cache for Redis 都可實作對等架構。

下一步路由

• 對照其他遊戲後端 → 9.C12 Riot Games EKS（cluster 隔離 vs 共用）
• 想設計遊戲 KV → 01 資料庫模組 + 9.C5 Amazon Ads
• 想理解 sub-ms latency 反推 → 9.C3 Coinbase + 9.12 SLO 與 Performance Budget
• 想規劃遊戲 KV access pattern 與 single-table design → DynamoDB single-table design
• 想評估遊戲流量的 on-demand vs provisioned → DynamoDB on-demand vs provisioned

引用源

• CAPCOM Case Study
• Amazon DynamoDB Customers
• Powering Gaming Applications with Amazon DynamoDB

觀察

Zomato 帳單系統遷移的關鍵數字（引自 AWS Database Blog）：

關鍵動機：TiDB 必須為「突發流量峰值」提前 over-provision、付出常態成本；DynamoDB on-demand 模式「pay only for what we use」、避免 over-provisioning。

判讀

Zomato 遷移揭露三個 DB 選型決策的判讀重點。

1. NewSQL vs NoSQL 的取捨不只是 schema：TiDB 提供 SQL 介面跟 ACID、DynamoDB 提供 KV 介面跟最終一致性。Zomato 選 DynamoDB 是判斷「帳單事件本身可以接受 eventually consistent」、用一致性換性能跟成本。對應 01.5 transaction boundary 的一致性取捨。
2. TiDB 必須 over-provision 是分散式 SQL 的常態：分散式 SQL 為了支援跨節點交易、必須有預留容量、否則峰值會出現 leader election storm 或 follower lag。這跟 9.C10 Spanner 的「節點數即容量」是同類取捨、Spanner 也必須預先 scale 節點。
3. 2K → 8K RPM 是 4 倍、但延遲降 90% 才是真關鍵：吞吐改善可能來自架構優化、延遲改善才是 DB 本質差。從 baseline → 10% 通常代表少了 1-2 個 hop（例如 cross-region replication、coordinator round-trip）。對應 9.1 壓測理論與系統行為 的 Little’s Law。

需要警惕：

• 「成本降 50%」是 當下流量下的對照。如果未來流量繼續成長、DynamoDB 的 cost-per-request 成長率比 TiDB 自管 cluster 高 — 達到某規模後 TiDB 反而更便宜。讀遷移案例要看「在當下流量下划算」、不等於「永遠划算」。
• 「90% 延遲降」可能只是 p50、p99 / p999 改善幅度通常較小。

策略

可重用的工程做法：

1. DB 遷移前先確認業務一致性需求：能接受 eventually consistent 的工作負載適合 KV / NoSQL；必須 strong consistency 的工作負載必須 SQL / NewSQL。對應 01.5 transaction boundary。
2. 遷移評估要看「總成本曲線」、不是「當下 snapshot」：算未來 12-24 個月在預期流量下的成本對照、不是只算現在。對應 9.7 成本邊界與 efficiency。
3. 遷移過程要 dual-write + shadow read 驗證：避免新舊系統行為不一致導致業務問題。對應 01.3 schema migration rollout evidence。
4. on-demand vs provisioned 的選擇與業務流量形狀對應：突發流量適合 on-demand、可預測流量適合 provisioned。對應 9.C15 Tixcraft 的 on-demand 應用。

跨平台等效：MongoDB Atlas → DynamoDB、Cassandra → DynamoDB、PostgreSQL → Aurora、CockroachDB → Spanner 都是常見遷移路徑。每條路徑的取捨類似。

下一步路由

• 想做 DB 遷移評估 → 01 資料庫模組 + 01.4 database migration playbook
• 想理解一致性取捨 → 01.5 transaction boundary + 9.C10 Spanner
• 想做總成本評估 → 9.7 成本邊界與 efficiency
• 對照其他 DB 遷移 → 9.C9 Spotify Kafka→Pub/Sub
• 想拆 access pattern 對應的 DynamoDB schema → DynamoDB single-table design + DynamoDB partition key 反模式
• 想評估搬遷後的 capacity mode → DynamoDB on-demand vs provisioned

引用源

• Unlocking performance, scalability, and cost-efficiency of Zomato’s Billing Platform by switching from TiDB to DynamoDB
• How Zomato Boosted Performance 25% and Cut Compute Cost 30% Migrating Trino and Druid Workloads to AWS Graviton

觀察

ASOS 在 Azure 的關鍵數字（引自 ASOS Microsoft Customer Story）：

關鍵業務驅動：「ASOS chose Azure Cosmos DB because of its global distribution and ability to handle heavy seasonal bursts like Black Friday」。

判讀

ASOS 案例揭露三個全球零售 KV 容量規劃重點。

1. Black Friday 24h 1.67 億 = 平均 1,930 req/sec、峰值 3,500 req/sec：峰值 / 平均 = 1.81 倍。這個比例顯示 Black Friday 「持續高峰」、不是「瞬間爆量」 — 24 小時內流量曲線相對平緩、跟 9.C15 Tixcraft 的「5 分鐘賣完」是完全不同形狀。對應 9.2 Workload Modeling 的負載形狀識別。
2. 48ms 平均響應 = 全球分散下 Cosmos DB 的代表性數字：英國時尚電商、客戶遍及全球、Cosmos DB 在每個地區複製、讀取在最近 region 完成。這個 48ms 包含網路、DB、應用層 — DB 本身可能只佔 5-10ms、其他是網路與應用層。對應 9.12 SLO 與 Performance Budget 的 latency budget 分解。
3. 85K SKU + 每週新增 5K = 高更新頻率 catalog：商品資料不只是讀、還有頻繁更新（價格、庫存、推薦排序）。這層 write throughput 對 Cosmos DB partition key 設計（通常用 category_id 或 brand_id）至關重要。對應 9.4 Saturation Discovery 的 hot partition 識別。

需要警惕：這是 2016 年的數字、過去 10 年 ASOS 應該成長很多。但 1.67 億 req/24h 跟 33 orders/sec 對許多新興電商仍是天花板級數字、可作為「中大型零售」對標。

策略

可重用的工程做法：

1. Black Friday 類「持續高峰」適合 provisioned + scheduled scaling：跟 flash-sale 的「on-demand 吃彈性」不同、Black Friday 整天高、用 provisioned 比較划算。對應 9.11 高峰事件準備 的可預期峰值準備。
2. 全球零售用 Cosmos DB / DynamoDB Global Tables：客戶在哪、讀取就在哪、避免跨洲 latency。對應 9.C10 Spanner 的全球分散取捨。
3. 微服務 + Cosmos DB 是電商現代化典型路徑：從單體 → 微服務、從關聯式 DB → multi-model NoSQL、是 2016 後零售業常見遷移。對應 01 資料庫模組 與 05 部署平台模組。

跨平台等效：AWS DynamoDB Global Tables + Lambda、GCP Firestore + Cloud Run 都可以實作對等架構。差異是 Cosmos DB 的 multi-model（同一服務支援 SQL、Mongo、Cassandra、Gremlin、Table API）、AWS 對應有 DynamoDB（KV/Document）+ Neptune（Graph）+ Keyspaces（Cassandra）等多個服務。

下一步路由

• 對照其他可預期峰值 → 9.C1 AWS Prime Day / 9.C13 Hotstar IPL
• 對照 flash-sale-spike → 9.C15 Tixcraft
• 想對照其他 Cosmos DB 使用 → 9.C11 Minecraft Earth
• 想規劃全球電商 → 01 資料庫模組 + 9.6 容量規劃模型
• 想拆 Black Friday 容量背後的 RU 成本與 sizing → Cosmos DB RU 成本模型與 sizing
• 想做電商 partition key 設計 → Cosmos DB partition key 設計

引用源

• ASOS – Online retailer uses cloud database to deliver world-class shopping experiences
• Azure Cosmos DB

觀察

Genesys Cloud 在 DynamoDB 的關鍵數字（引自 Genesys DynamoDB Case Study）：

關鍵架構決策（引述 Chief Architect Rob Gevers）：「Amazon DynamoDB is our primary data layer by default, and teams have to justify the use of something else.」

判讀

Genesys 案例揭露三個 B2B SaaS 平台容量規劃重點。

1. B2B 可用性目標跟 C2C 不同：B2C 大型網站可能接受 99.9%（年停機 8.76 小時）、B2B SaaS 經常合約規定 99.95% 或 99.99%、客服平台類甚至要 99.999%（年停機 5 分鐘）。每多一個 9、容量規劃跟運維成本指數成長。對應 9.12 SLO 與 Performance Budget 的 SLO 等級設計。
2. 「DynamoDB 為預設、用其他要 justify」是規模化平台的工程治理：跟 9.C23 Netflix 整合到 Aurora 是同樣訴求、不同實作 — Genesys 選 DynamoDB 為基準是因為「Multi-region active-active」+「自動 scaling」+「99.999% SLA」的組合最容易達成 5 個 9 目標。對應 01 資料庫模組 的 DB 預設選型。
3. 15 主 region + 5 衛星 region = 全球客戶就近接入：客戶服務有強烈延遲敏感（agent 操作介面卡 1 秒、客服效率掉一半）、必須在客戶所在地有 region。跟 9.C12 Riot Games 246 cluster 的延遲驅動 region 部署同類思維。對應 9.6 容量規劃模型 的地理分散規劃。

需要警惕：

• 「99.999% over 12 months」是 截至特定時間點的歷史值、不代表「未來持續達成」。可用性是滾動指標、不是恆久承諾。
• 案例 沒有 提具體 QPS / RPS、訊息量、延遲分布。讀者要對 策略 學習、具體數字需要自己壓測。

策略

可重用的工程做法：

1. B2B SaaS 平台優先選 multi-region active-active 資料層：DynamoDB Global Tables、Cosmos DB Multi-Region Write、Spanner multi-region 都是候選。對應 01.5 transaction boundary 的全球一致性取捨。
2. 「預設 DB」原則簡化 onboarding：新團隊不用評估十種 DB、預設用 X、特殊需求再 justify。減少團隊認知負擔、加速產品開發。對應 9.C23 Netflix 的 DB 整合。
3. 99.999% 必須有 redundancy 在每一層：DNS、load balancer、application、database、storage 都要跨 region active-active。任何一層 single-region 就破壞整體 SLO。對應 05 部署平台模組 跟 06 可靠性驗證模組。
4. 多 region 是成本 vs 可用性的硬取捨：15 個 region 的成本約是 1 個 region 的 15 倍 — 對 B2B SaaS 是合理投資、對 B2C 通常不划算。

跨平台等效：Azure Cosmos DB Multi-Region Write、GCP Spanner multi-region、Cassandra multi-DC 都可實作對等架構。差異是 region 數量、SLA 承諾、跨 region 延遲。

下一步路由

• 想設計 B2B SaaS 可用性 → 9.12 SLO 與 Performance Budget + 06.6 SLO 與 Error Budget 政策
• 想設計多 region 資料層 → 01 資料庫模組 + 9.C10 Spanner
• 想做 DB 統一治理 → 9.C23 Netflix Aurora consolidation + 00 服務選型模組
• 想規劃跨 region 容量 → 9.6 容量規劃模型 + 9.C12 Riot Games
• 想理解 DynamoDB 99.999% 背後的 partition / GSI 設計 → DynamoDB partition key 反模式 + DynamoDB GSI / LSI 設計
• 想對應 global tables 多 region 寫衝突 → DynamoDB global tables 寫衝突

引用源

• Genesys Achieves 99.999% Availability Using Amazon DynamoDB
• Amazon DynamoDB Customers

觀察

PayPay 在 DynamoDB 的關鍵敘述（引自 DynamoDB Customers）：

判讀

PayPay 案例揭露三個行動支付訊息系統的工程重點。

1. 支付通知是「不可丟失 + 不可延遲」雙重需求：用戶付完款 30 秒沒收到通知會懷疑系統壞了、會打客服 / 重複扣款。這層需求比 OTA 推播嚴格、必須有 durable queue + retry + 重複偵測。對應 03 訊息佇列模組 的 idempotency 設計。
2. DynamoDB 在「訊息事件」這類負載特別適合：每則訊息有獨立 message_id（partition key 天然均勻）、TTL 機制可以自動清理過期訊息（避免 storage 爆炸）。對應 9.C5 Amazon Ads 的 partition 均勻優勢、跟 02.4 cache copy freshness boundary 的 TTL 議題。
3. 3 億 / 天 ≈ 3,500 訊息 / 秒平均：聽起來不大、但這是 平均。月底、雙 11 類大促、新年紅包等場景、單秒峰值可能達 10x-50x。對應 9.2 Workload Modeling 的峰均比評估。

需要警惕：「super reliable」是行銷語言、不是工程承諾。讀此類短篇案例要把行銷敘述折扣、重點看 服務組合 與 規模量級。

策略

可重用的工程做法：

1. 訊息系統設計區分「通知」跟「訊息」：通知（payment received）是 transactional、不可丟失；訊息（marketing）可以丟失部分、重點是 throughput。兩者用不同 SLO、不同 storage。對應 03 訊息佇列模組 的訊息分類。
2. TTL 自動清理避免 storage 成本爆炸：3 億 / 天 × 30 天 = 90 億筆記錄、不清理會撐死 storage 預算。對應 02 快取模組 的 TTL 設計。
3. 訊息推送的下游（APNs、FCM、SMS gateway）是隱性瓶頸：DynamoDB 寫入可以撐 3K msg/sec、但 APNs 一天的 quota 是有限的。對應 9.5 瓶頸定位流程 的依賴鏈分析。

跨平台等效：GCP Firestore + Cloud Messaging、Azure Cosmos DB + Notification Hubs 都是對等架構。差異是 vendor 整合度跟全球分發能力。

下一步路由

• 想設計行動支付訊息 → 03 訊息佇列模組 + 9.5 瓶頸定位流程
• 對照其他 KV 高吞吐 → 9.C5 Amazon Ads / 9.C18 Zoom
• 想做訊息系統容量規劃 → 9.6 容量規劃模型 + 9.2 Workload Modeling
• 想避免訊息熱點打爆單一 partition → DynamoDB partition key 反模式
• 想評估訊息系統的 capacity mode → DynamoDB on-demand vs provisioned

引用源

• Amazon DynamoDB Customers
• PayPay on AWS

觀察

Disney+ 在 DynamoDB 的關鍵敘述（引自 DynamoDB Customers）：

每個用戶動作（播放、暫停、跳過、加入 watchlist、評分）都是一次 DynamoDB 寫入。每次打開 app 又是多次讀（自己的 watchlist、最近播放、繼續觀看）。

判讀

Disney+ 案例揭露三個串流平台 metadata 層的工程重點。

1. 「每日數十億動作」= read + write 都要撐：跟 9.C5 Amazon Ads 的 18:1 讀寫比不同、串流 metadata 通常接近 5:1 read-heavy（每動作 1 寫、每 session 5 讀）。partition key 設計通常用 user_id、天然均勻、不會 hot partition。對應 01 資料庫模組 的 schema design。
2. 新片發布是 predictable-peak：Marvel / Star Wars / Disney 動畫 新片上線首日、metadata 流量可衝 3-5 倍 — 因為「全平台用戶同時打開該片頁面」。這比一般 Black Friday 集中、像 9.C13 Hotstar IPL 的集中型流量。對應 9.11 高峰事件準備 的內容發布事件容量規劃。
3. watchlist + 播放進度需要跨裝置即時同步：用戶在手機看到一半、晚上回家用電視繼續、進度必須跨裝置同步。這層需求對 DynamoDB Global Tables（multi-region active-active）特別適合。對應 01.5 transaction boundary 的最終一致性可接受場景。

需要警惕：「billions of actions daily」沒指明具體數字（10 億、100 億 還是 數十億？）。讀此類短篇案例只能取「量級對標」、不能套用具體數字。

策略

可重用的工程做法：

1. 串流平台分「metadata 層」「content delivery 層」：metadata（watchlist、播放進度、推薦）用 DynamoDB / Cosmos DB；content（video file）用 CDN + S3 / object storage。兩者完全分開、互不影響。對應 05 部署平台模組 的 control plane vs data plane、跟 9.C18 Zoom 的同類思維。
2. 新片發布像 mini Black Friday、要 pre-scaling：發布時間已知、流量倍數可預估（根據前幾部）、可以提前 1-2 天 pre-scale DynamoDB capacity。對應 9.11 高峰事件準備。
3. DynamoDB Global Tables 是跨裝置同步的有效方案：用戶在不同 region 登入同帳號、寫入會自動同步到其他 region。對應 9.C24 Genesys 的 multi-region active-active。

跨平台等效：Netflix 同類 metadata 用 Cassandra + EVCache（9.C23 Netflix 提及）、HBO Max 用 Aurora、Apple TV+ 用 FoundationDB + Cassandra — 各家串流的 metadata 技術棧不同、但「分層解耦」的工程哲學一致。

下一步路由

• 對照其他串流案例 → 9.C13 Hotstar IPL（live）/ 9.C29 NTT DOCOMO Lemino
• 想理解 metadata 層 → 01 資料庫模組 + 9.5 瓶頸定位流程
• 想做內容發布 pre-scaling → 9.11 高峰事件準備 + 9.C1 Prime Day
• 想做跨裝置同步設計 → 9.C24 Genesys multi-region
• 想拆 metadata 的 single-table 與 GSI 設計 → DynamoDB single-table design + DynamoDB GSI / LSI 設計
• 想做跨 region metadata 一致性 → DynamoDB global tables 寫衝突

引用源

• Amazon DynamoDB Customers
• Amazon DynamoDB use cases for media and entertainment customers

觀察

NTT DOCOMO Lemino 在 AWS 的關鍵數字（引自 Lemino Case Study）：

服務組合：AWS Media Services（Elemental Link、MediaConnect、MediaLive、MediaPackage）、Amazon Aurora、Amazon DynamoDB、DynamoDB Accelerator (DAX)、Amazon OpenSearch Service。

關鍵敘述：採用 DynamoDB 的原因 — 「connection limits became bottlenecks when experiencing a rapid increase in access」。

判讀

Lemino 案例揭露三個現代串流服務啟動的工程重點。

1. 「connection limit 是 RDB 的隱性 bottleneck」是 OLTP 在 surge 下的典型問題：傳統 RDB（PostgreSQL、MySQL）每個連線吃記憶體跟 process / thread、connection pool 上限通常 1K-5K 個。當突發流量湧入、第一個爆的不是 CPU 也不是 disk、是 連線數量。DynamoDB 的 HTTP API 模型沒有 connection state、天然解決這個問題。對應 01 資料庫模組 的 connection pool 議題、跟 9.C20 Zomato 遷移動機同類。
2. AWS Media Services 是「電視台級」串流基礎設施：Elemental Link（encoding）、MediaConnect（transport）、MediaLive（live encoding）、MediaPackage（packaging + DRM）— 這套 stack 過往是電視台才買得起的硬體設備、AWS 把它變成 pay-per-use 服務。對應 05 部署平台模組 的 vendor-specific 串流服務評估。
3. 90% 工程工時下降 = 走 managed 路線的真正價值：傳統電信商 launch 串流服務、要養 50-100 個 SRE + DBA + network 工程師、Lemino 用 managed 服務只需 5-10 個。差距不在「能不能 launch」、在「launch 後的維運成本」。對應 9.C19 Capcom 的同類訴求。

需要警惕：「tens of thousands req/sec」可能指 2 萬或 8 萬、差距 4 倍。「3 個月 5M MAU」很亮眼、但 NTT DOCOMO 自身有 8000 萬+ 電信用戶可以推、不是純自然成長。

策略

可重用的工程做法：

1. 新串流服務優先選 DynamoDB / Cosmos DB / Bigtable 撐 metadata 層：避免 connection limit、避免 schema migration、避免 DBA 維運成本。
2. AWS Media Services / GCP Media CDN / Azure Media Services 是新進入者快速 launch 的捷徑：不要重造串流 stack、直接用 vendor 提供的。
3. DAX 是 DynamoDB 讀 cache 的標準解法：當讀峰值持續高（例如熱門節目首播、Hotstar 等級）、加 DAX 減少 DynamoDB 讀次數、降低成本。對應 02 快取模組。
4. 小團隊 + managed services 是電信商雲端轉型的範本：傳統電信商過去靠人海戰術、現在改靠 managed + 工程紀律。

跨平台等效：GCP 提供 Media CDN + Anvato，Azure 提供 Media Services + Azure Front Door — 各家都有完整串流 stack。

下一步路由

• 對照其他串流案例 → 9.C13 Hotstar IPL（live 直播）/ 9.C27 Disney+（VOD metadata）
• 想理解 connection limit 議題 → 01 資料庫模組 + 9.C20 Zomato 遷移
• 想做 DAX / cache 加速 → 02 快取模組 + 9.C25 Tubi ML feature store
• 想規劃 managed-only 串流 stack → 05 部署平台模組 + 00 服務選型模組
• 想做串流 metadata 的 partition / GSI 設計 → DynamoDB partition key 反模式 + DynamoDB GSI / LSI 設計
• 想評估 on-demand vs provisioned 給直播 / VOD 用 → DynamoDB on-demand vs provisioned

引用源

• NTT Docomo Rebuilds Infrastructure for Lemino Streaming Service Launch
• Direct to Consumer & Streaming on AWS