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.6 How do live ingest and segmenting work?
3 min read+10 XP
Step 5: Deep dives (10 minutes)
- Contribution: the broadcaster sends a high-quality feed (over dedicated links or protocols like SRT/RTMP) to redundant ingest points.
- Encode: live encoders turn it into the ladder (Chapter 40) in real time; every rendition must line up on the same keyframes so players can switch quality between segments.
- Package: cut into segments, write rolling playlists (the latest few segments), and push to the origin.
Latency is mostly set by segment length and how many segments the player buffers:
Figure: shorter segments cut delay, at the cost of more requests and less cushion against a bad network.
In the chapter's code: 6-second segments with 3 buffered put viewers about 27 seconds behind the stadium; 2-second segments about 11 seconds; low-latency modes with 1-second partial segments (LL-HLS, low-latency DASH) about 6 seconds. Pick based on the product: a few seconds' less delay is worth a lot when neighbours with TV are cheering before your phone shows the six.
Memory code: "Shorter segments, shorter delay, smaller cushion."