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.9 How does live score sync work?
3 min read+10 XP
Two problems: scale and spoilers.
Scale: pushing every ball to 25 million sockets is heavy. A cached JSON file is far cheaper:
- Players poll
score.jsonevery ~10 seconds. That's about 2.5 million requests a second, served from CDN caches with a ~2-second TTL. - Our servers see roughly one request per CDN location per TTL: about 100 a second in the chapter's code.
- Alternatively, carry the score inside the video as timed metadata in the segments, so it arrives exactly with the frames it describes.
Spoilers: the official data feed is ahead of the video by the stream's delay. If the app shows "OUT!" 20 seconds before the viewer sees the wicket, it ruins the moment. Each score event carries match time; the app shows the latest event that isn't ahead of the video position it's playing. In the chapter's code, a viewer whose video is at match time 135 sees "IND 126/2 (SIX!)", not the wicket at 160 that has already happened in the stadium.
Memory code: "Poll a cached score, and never show what the video hasn't shown yet."