這個案例的核心責任是說明「全球大型直播」的容量設計 — 跟 Prime Day 同屬「可預期極端峰值」、但形狀完全不同：Prime Day 是分散全球的購物峰值、Hotstar IPL 是 單一時間點 + 高度集中地理區 的直播峰值。容量規劃的挑戰在於 CDN、串流伺服器、live encoder、message queue 同時 saturate。

觀察

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

指標數字
同時觀看峰值1860 萬 人（2019 年 5 月 IPL 決賽）
全球記錄該時點全球同時觀看直播的最高記錄
服務組合AWS Media Services + AWS CloudFront（推論，引用頁沒有寫）
客戶基礎印度為主、跨亞洲

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 萬同時觀看」是 峰值瞬間、不是全程平均。依一般直播的形狀推論（引用頁沒有寫），決賽數小時、觀眾數呈鐘形曲線、峰值維持時間可能只有比賽關鍵時刻的一段。容量規劃要看峰值持續時間、不只看峰值高度。

策略

可重用的工程做法：

  1. CDN 容量規劃按地理區分割：不要假設「全球 CDN 總量」夠用、要按主要觀眾分布的地區做容量保證。對應 9.6 容量規劃模型。
  2. 直播的擴展要先量出反應時間、換算成緩衝：Hotstar 自己的工程文寫道，事前悲觀地把容量擴到預期同時在線人數「was resulting in a heavy infrastructure costs」，所以 2019 年開始試用自建的 autoscaler；文中的估算假設加節點約 90 秒、容器建立與應用啟動約 75 秒，加上收集指標與決策，總延遲約 4 分鐘，「we would have missed about two million people on the platform within these 4 minutes」；直播期間的緩衝因此設為依同時在線人數分階擴展的服務多加 200 萬，依請求數擴展的服務加 30%（Scaling for tsunami traffic，Wayback）。對應 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 處理能力。

下一步路由

引用源