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.1 What do you ask first?
3 min read+10 XP
Step 1: Requirements (5 minutes)
| Letter | Candidate asks | Interviewer answers |
|---|---|---|
| Scope | "One live stream, or many? Different languages or camera angles? Rewind? Ads? Live score?" | "One match, a few language commentary feeds. Live score yes. Short rewind (DVR) is nice to have. Ads exist but aren't the focus." |
| Count | "How many viewers at peak?" | "Plan for 25 million concurrent, with growth." |
| Access pattern | "How fast does the audience change?" | "It can jump from 5 to 25 million in ten minutes when a star comes out to bat, and drop during breaks." |
| Latency | "How far behind real time is acceptable?" | "Under ~30 seconds; less is better. It must not stall." |
| Exactness | "Must the score match the video?" | "The score shouldn't spoil what the viewer hasn't seen yet." |
Agreed requirements:
- Functional (verbs): ingest the stadium feed; encode and package it live in several qualities; deliver it to tens of millions of devices; show a live score in sync with the video; sign in and check entitlement.
- Non-functional (adjectives): massively scalable delivery (tens of Tbit/s), no stalls under huge, sudden spikes, low latency (seconds to tens of seconds), highly available end to end (a dead encoder during a final is front-page news), no spoilers.
Interviewer pushback:
- "What's harder than video on demand?" → Everything is concentrated: one stream means the same few segments requested by millions at the same second, and the audience changes faster than servers boot. You can't cache your way out of a spike in API calls, and you can't autoscale your way out of a spike that arrives in minutes.
Memory code: "One stream, everyone at once, doubling in minutes."