觀察

Hotstar IPL 直播的關鍵數字（引自 Hotstar global record）：

AWS Media Services 在大型事件的歷史記錄：Olympics、Super Bowl、IPL Cricket（引自 AWS large-scale streaming events）。

判讀

Hotstar 案例揭露三個全球直播容量重點。

1. 集中地理區 = CDN 壓力集中：Prime Day 的流量分散全球、單一地區 CDN 不會 saturate；IPL 主要觀眾在印度、所有印度 PoP 同一時間 saturate。CDN 容量規劃必須按地區獨立做、不能用「全球總容量」當保證。對應 04 可觀測性模組 的 cardinality 與地區訊號治理、跟 9.6 容量規劃模型 的「地理分片容量」。
2. 直播跟 VoD 是不同容量問題：VoD 觀眾分散時間、CDN 可預先 cache；直播觀眾集中時間、每一個 manifest / segment 都是 live 拉取、cache hit 反而是危險（拉到舊的 segment）。對應 02 快取模組 的 cache freshness boundary、跟 03 訊息佇列 的 fan-out 設計。
3. 多 bitrate 動態切換 = 真實容量是 bitrate 加權：1860 萬觀眾不是都看 1080p — 印度行動網路下大多看 720p 或 480p、bitrate 加權後的 total bandwidth 可能比想像低。對應 9.2 Workload Modeling 的真實 workload shape。

需要警惕：「1860 萬同時觀看」是 峰值瞬間、不是全程平均。決賽 4 小時、觀眾數呈鐘形曲線、峰值維持時間可能只有 10-30 分鐘（比賽關鍵時刻）。容量規劃要看峰值持續時間、不只看峰值高度。

策略

可重用的工程做法：

1. CDN 容量規劃按地理區分割：不要假設「全球 CDN 總量」夠用、要按主要觀眾分布的地區做容量保證。對應 9.6 容量規劃模型。
2. 直播必須 pre-scaling、不能依賴 reactive：直播開始之後 CDN reactive 擴容已經太晚、觀眾體驗已壞。事件型 scheduled scaling + over-provisioning 是必須。對應 9.11 高峰事件準備。
3. multi-bitrate / ABR streaming 是容量緩衝：當網路擁塞、player 自動降 bitrate、總頻寬壓力下降。這層降級是隱性容量緩衝、要在壓測時驗證。對應 9.4 Saturation Discovery 的 saturation 行為。

跨平台等效：GCP CDN + Media CDN、Azure Front Door + Media Services、Akamai / Cloudflare / Fastly 等 multi-CDN 都是對等候選。差異是 PoP 地理分布跟 manifest 處理能力。

下一步路由

• 想規劃全球直播 → 9.11 高峰事件準備 + 9.6 容量規劃模型
• 想做 CDN 容量設計 → 05 部署平台模組 + 04 可觀測性模組
• 想理解 cache freshness 在直播的影響 → 02.4 cache copy freshness boundary
• 對照其他可預期峰值 → 9.C1 AWS Prime Day（分散全球的峰值）

引用源

• In the news: Hotstar sets new global record for live viewership
• Large scale streaming events on AWS
• Direct to Consumer & Streaming on AWS

觀察

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

觀察

Wayfair 在 GCP 的關鍵敘述（引自 Wayfair Case Study）：

服務組合：BigQuery（資料倉儲）、Cloud Dataproc（資料處理）、Cloud Pub/Sub（資料注入）、Looker（dashboard）、Cloud DLP（合規）、C2 processors（高性能 compute）。

關鍵敘述：「Our automation systems signal the cloud to scale on demand」「We were able to reduce and eventually eliminate the need for change freezes leading up to big events」。

判讀

Wayfair 揭露三個 hybrid cloud burst 模式的工程重點。

1. Hybrid burst 是「容量規劃成本平衡」的折衷：自家 data center 平日跑得便宜、峰值事件不夠用；全部上雲峰值好辦但平日成本高。Hybrid 模式讓 baseline 用便宜的、峰值用彈性的、總成本曲線最平。對應 9.7 成本邊界與 efficiency 的長期 TCO 規劃。
2. 「Change freeze 不再需要」是 burst 模式的真正價值：傳統零售 IT 為了 Black Friday 通常 2-3 個月前就 freeze code change、確保穩定。Wayfair 在 GCP burst 上線後、能在峰值前繼續正常 release — 因為新功能可以單獨 deploy 到 GCP、不影響 on-prem 主系統。對應 06.8 release gate 的非凍結式變更管理。
3. 資料平面（BigQuery / Dataproc）是 hybrid 的主場、交易平面仍在 on-prem：Wayfair 把「分析、報表、推薦模型」放 GCP、「核心交易、訂單處理、庫存」仍在自家。這個切分是 hybrid 的常見做法 — 計算密集的工作上雲、業務核心保留自管。對應 01 資料庫模組 的核心 OLTP 跟 04 可觀測性模組 的分析資料層分離。

需要警惕：

• Wayfair 案例 沒有 提具體 TPS、latency、capacity scale 數字 — 行銷敘述居多、工程細節較少。讀此類案例要對 策略 做學習、不要套用具體數字。
• 「82.5% 美國淨營收成長」是 業績、不是 系統指標。系統能撐業績、但兩者不是同一件事。

策略

可重用的工程做法：

1. Hybrid burst 適合「業務核心 on-prem 已穩定 + 季節性 / 事件型峰值」的企業：對於全新雲原生 startup、直接全上雲更簡單；對於有 15-20 年自建系統的大企業、hybrid 是穩妥路徑。
2. 資料平面先上雲、交易平面後上：BI、ML、推薦這類「計算密集 + 資料量大 + 容忍延遲」適合先上 GCP / AWS / Azure；OLTP 後續再評估。對應 9.C17 BookMyShow 的資料層先行模式。
3. automation signal + 雲端 burst 是「change freeze」的解法：監控訊號 → 自動 trigger 雲端容量 → 平滑釋放 → 不影響 on-prem 主系統的部署節奏。對應 9.11 高峰事件準備。

跨平台等效：AWS Outposts + AWS Direct Connect、Azure Arc + ExpressRoute、Equinix + 各雲商 PrivateLink 都是 hybrid burst 的基礎設施。差異是各家 hybrid 策略成熟度。

下一步路由

• 想規劃 hybrid cloud burst → 9.6 容量規劃模型 + 9.11 高峰事件準備
• 想做資料平面遷移 → 9.C17 BookMyShow + 01 資料庫模組
• 對照全雲原生 → 9.C15 Tixcraft
• 想取消 change freeze → 06.8 release gate + 06.17 feature flag governance

引用源

• Wayfair Case Study (Google Cloud)
• Way Day 2019 burst capacity

觀察

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