Design Live Streaming Platform

Build a platform where anyone can broadcast live video and anyone else can watch it, in the style of Twitch, Kick or YouTube Live. Creators send one high quality stream from software like OBS. Viewers pick a channel and get smooth playback at whatever quality their network allows, plus a live chat. When a broadcast ends, it is kept as a replay for a while.

What makes this hard is the combination of three pressures. Video is expensive to process: every incoming stream needs real-time encoding into four or five renditions. Delivery is enormously asymmetric: one input becomes millions of outputs, and the popularity of channels is extremely skewed. And everything is on a clock, because a stream that falls ten seconds behind feels broken when chat is reacting to something the viewer has not seen yet.

Take a peak evening with 90,000 channels live at once and 9 million concurrent viewers. Assume creators send 1080p60 at 6 Mbps and viewers average 3.5 Mbps across the ladder. Chat is busiest in the largest channels.

A creator's encoder connects to the nearest ingest point of presence, picked by DNS or anycast. Ingest servers are thin: they check the stream key, accept the RTMP or SRT session and forward the raw stream over the provider's backbone to a transcoding cluster in the same region. Keeping the first hop short matters because packet loss on the creator's last mile is the most common source of stutter.

The transcoder decodes the source and re-encodes it into a ladder, perhaps 1080p60, 720p60, 480p, 360p and 160p, all aligned on the same keyframe boundaries so the player can switch between them cleanly. A packager cuts each rendition into short CMAF segments and partial segments, writes them to an origin store, and updates the playlists. A copy of the source rendition goes to the replay archive.

Viewers never touch the origin directly. Their players fetch playlists and segments from CDN edges, which fall back to a regional origin shield on a miss, which falls back to the origin. Chat is a separate system that shares nothing with the video path except the channel ID.

A viewer on hotel Wi-Fi cannot sustain 6 Mbps, so you encode the same picture several times at different sizes and let the player choose. A sensible ladder is the source at 1080p60, then 720p60 at about 3.5 Mbps, 480p at 1.5 Mbps, 360p at 0.8 Mbps and an audio-heavy 160p for poor connections. Every rendition must put keyframes at exactly the same timestamps, typically every two seconds, because the player can only switch rendition at a keyframe.

Transcoding in real time is the main compute bill. Software x264 at a fast preset gives good quality per bit but needs a lot of CPU for 1080p60. Hardware encoders on GPUs or dedicated chips are far cheaper per stream with slightly worse compression. Large platforms often mix both: hardware for the long tail, careful software encodes for the biggest channels where every saved bit multiplies across a million viewers.

To avoid paying for ladders nobody watches, start every new broadcast in passthrough mode where viewers get only the source. When the viewer count crosses a threshold, perhaps five, the scheduler assigns a transcoder slot and the master playlist gains extra renditions on its next refresh.

CDNs are excellent at serving files, so we turn video into files. The packager cuts each rendition into fixed-length segments in CMAF (fragmented MP4) and writes a playlist that lists the most recent few. Players poll the playlist, download new segments and play them in order. The playlist is the only object that changes; the segments are immutable and can be cached with long lifetimes.

With classic 6-second segments and a three-segment buffer, latency lands near 20 seconds. Shorter segments help, but a 1-second segment means a keyframe every second, which hurts compression. Low-Latency HLS solves this by publishing partial segments of about half a second as they are produced, while full segments keep their two-second keyframe interval. The playlist advertises the next part before it exists, and the player issues a blocking request that the edge holds open until the part arrives. With three parts buffered, the player sits around 1.5 seconds behind the live edge.

When a big channel goes live, hundreds of thousands of players ask for the same new part within the same half second. Without care, each CDN edge misses and asks the origin at once. Two mechanisms stop that. Request collapsing at the edge sends one upstream fetch per object and parks the other requests on it. An origin shield per region adds a second layer, so the origin sees a handful of requests per segment, not one per edge.

Playlists need a short TTL, about half the part duration, while segments can be cached for minutes. For the very largest events you can pre-position by pushing segments to edges instead of waiting to be pulled, or spread the load across two CDN providers with a traffic steering layer that shifts viewers when one degrades.

Viewers connect to a WebSocket edge, which subscribes to the room on a pub/sub tier. When someone sends a message, the edge validates it, applies rate limits and moderation filters, and publishes it to the room. Every edge holding members of that room receives one copy and writes it to each local socket. A room of 500,000 people spread over 400 edges costs 400 internal deliveries per message, not 500,000.

Huge rooms produce more text than anyone can read. Past a few hundred messages per second, the edge samples or batches, sending a bundle every 200 milliseconds. Nobody notices a dropped "LUL" among thousands; everybody notices a frozen chat.