Art of Codeartofcode
Lesson 6 of 15

41. Design Live Streaming at Scale (Live Cricket)

1
The interview prompt
2
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 yourself
13
Variations to practise
14
Sources
15
Code lab
41. Design Live Streaming at Scale (Live Cricket)

41.5 What does the whole system look like?

3 min read+10 XP

Step 4: High-level design (10 minutes)

the stadium feed reaches redundant ingest, live encoders and a packager; segments go to an origin, through shields to CDN edges and ISP caches, to 25 million players; a score service and an API tier sit beside it, pre-scaled.

Figure: one stream in, millions out; almost all the load is delivery and the API calls that start a session.

Video, step by step:

  1. The stadium feed reaches two ingest points over separate network paths.
  2. Live encoders produce the ladder of qualities (Chapter 40) in real time; a packager cuts them into 2-6 second segments and updates the playlists every segment.
  3. Segments go to the origin, then through shields to CDN edges and ISP-embedded caches (Chapter 26).
  4. Players fetch the playlist, then segments, adapting quality (Chapter 40), staying ~10-30 seconds behind live.

Starting to watch:

  1. The app signs in and calls the play API, which checks entitlement (cached ahead of time) and returns a signed playlist URL.
  2. From then on, the player talks only to the CDN; our API tier is involved again only for ads and the occasional refresh.

Interviewer pushback:

  • "An encoder dies mid-over." → Run encoders in pairs (in two locations) producing identical, time-aligned output; the packager or origin switches to the healthy one. Players see at most a brief quality drop.
  • "Rain stops play, and 20 million people close the app; when play resumes they all reopen it." → That's a thundering herd on sign-in and the play API (Chapter 21). Pre-scale for it, cache entitlements, keep tokens long enough not to need a refresh, and shed non-essential calls.

Memory code: "Two of everything upstream, the CDN for everything downstream."

Offer: "The interesting parts are live ingest and latency, the CDN at peak, pre-scaling for spikes, and syncing the score. Which would you like?"