Twitch

Live streaming platform

Design a live video platform where creators broadcast from their computers and millions of people watch a few seconds behind, with a busy chat room beside every stream.

Overview

A live streaming platform takes video that a creator is broadcasting right now and plays it to everyone watching, a few seconds later. It looks like on-demand video, but there is no file to prepare in advance: every second of video is uploaded, converted and delivered while the next second is being recorded. Viewers also talk to the creator in chat, so the delay between the creator's camera and the viewer's screen (glass-to-glass latency) decides whether a conversation feels live.

Three things make it hard at this scale. Video is heavy, so delivery bandwidth dwarfs everything else and must come from servers close to viewers. The delay budget is a few seconds, and the way video is cut into pieces for delivery uses most of it. And audiences are skewed: a few channels have hundreds of thousands of viewers and a chat room to match, while most have a handful, so the design must be cheap for the small channels and survive the big ones.

Questions to ask first

How many viewers and channels? — 5 million concurrent viewers and 200,000 live channels at peak
How far behind live may viewers be? — Under 5 seconds for most viewers; about 10 is the fallback
Which qualities? — The creator's source plus a ladder of lower renditions for busy channels
Chat? — Yes, one room per channel, open to all viewers; up to hundreds of thousands in a room
Replays? — Broadcasts are saved as VODs for a limited time; viewers can clip moments
Devices? — Browsers, phones and TVs, so a widely supported HTTP delivery format

What you will be able to do

Trace a frame from the creator's software through ingest, transcoding and delivery to a player.
Explain how segment length sets latency, and how low-latency HLS cuts it.
Size delivery and explain why a replication tree of caches, not the origin, serves viewers.
Design chat for a room with hundreds of thousands of people.
Handle skew: which channels get transcoding, and what happens when a small channel suddenly gets huge.

Key concepts

RTMP ingest
Edge PoPs and origins
Transcoding ladder
HLS segments and playlists
Low-latency HLS
Replication tree
Chat fan-out
Viewer counts
VOD and clips

Functional requirements

A creator starts a broadcast from streaming software with a secret stream key
Viewers watch live at the best quality their connection allows
Each channel has a chat room; messages appear for everyone in about a second
Followers get a notification when a channel goes live
A browse page lists live channels by category and viewer count
Broadcasts can be saved as VODs, and viewers can clip a recent moment

Non-functional requirements

Glass-to-glass latency under 5 seconds for most viewers (a target we chose)
Chat messages reach viewers within 1 second at p99 (a target we chose)
A channel can grow from a few viewers to hundreds of thousands in minutes
Losing an edge site or an origin interrupts streams for seconds, not the rest of the broadcast
Delivery cost scales with viewers, not with viewers times origins

Interview questions

Walk through the path of a frame from the creator to a viewer.
Why is live video 10 seconds behind, and how do you get it to 3?
How do you serve one stream to a million viewers?
How does chat scale to a room with hundreds of thousands of viewers?
Which channels get transcoded?
What happens when an origin fails mid-broadcast?
How are VODs and clips made?
How do you show viewer counts on the browse page?