41. Design Live Streaming at Scale (Live Cricket)
1
The interview prompt2
41.1 What do you ask first?3
41.2 How big is this, really?4
41.3 What are the doors?5
41.4 What do we store?6
41.5 What does the whole system look like?7
41.6 How do live ingest and segmenting work?8
41.7 How does the CDN cope at peak?9
41.8 How do you pre-scale for spikes?10
41.9 How does live score sync work?11
41.10 What would you say in the last five minutes?12
Score yourself13
Variations to practise14
Sources15
Code lab41. Design Live Streaming at Scale (Live Cricket)
41.7 How does the CDN cope at peak?
3 min read+10 XP
At 25 million viewers, the same segment is requested millions of times within a few seconds of being published:
- Edges and ISP caches serve almost all of it. Live segments are perfect cache objects: identical for everyone, immutable once written.
- Request collapsing at every layer: when a new segment is published, thousands of requests for it arrive at an edge before it's cached; the edge forwards one to the shield, and the shield one to the origin (Chapter 26). In the chapter's code, each new segment reaches the origin about 60 times (6 renditions × 10 shields), not millions.
- Playlists change every segment, so give them a TTL around the segment length (a second or two), and collapse requests for them too.
- Capacity reservation: for a known final, agree capacity in advance with CDN providers and ISPs, and spread traffic across multiple CDNs (Chapter 26) so one provider's trouble doesn't take down the match.
- Bitrate caps as a safety valve: if total demand nears the network's limit, cap the highest quality for everyone (say 720p) rather than let everyone stall.
Memory code: "Millions ask, one request goes upstream."