Skip to content

00. Design a Live Streaming Platform (Twitch)

~20 min read · Level: advanced · Part 1 of 4 (Overview → HLD → LLD → Q&A)

Problem

A live streaming platform ingests a broadcaster's real-time video, transcodes it on the fly, and fans it out to millions of concurrent viewers with low delay — plus a live chat scrolling alongside. This is Twitch/YouTube Live. Unlike video-on-demand, you cannot pre-encode or pre-warm anything: the content doesn't exist until the moment it's streamed, so every stage happens in a tight real-time pipeline while viewers are already watching.

Thread one scenario: an esports grand final with one broadcaster and 5 million concurrent viewers, where the play-by-play must reach viewers within a few seconds and 500,000 of them are typing in chat during a clutch moment. Low glass-to-glass latency for the video and a chat that doesn't melt down are the two things this study must deliver.

Functional requirements

  • Broadcaster ingest: push a live video/audio stream to the platform.
  • Real-time transcode into multiple renditions (ABR).
  • Fan out the live stream to millions of concurrent viewers with low latency.
  • Live chat per stream, scaling to hundreds of thousands of concurrent chatters.
  • Optional DVR/VOD: record the stream for later replay.

De-scoped: monetization, moderation ML (see the content-moderation study), and recommendations. VOD replay reuses the OTT study's pipeline once the stream ends.

Non-functional requirements

The dominant constraint is low end-to-end (glass-to-glass) latency at massive viewer fan-out — a fundamentally different tradeoff from VOD, which optimizes throughput over latency.

  • Latency: video glass-to-glass in the low single-digit seconds (lower for interactive streams).
  • Availability: the live pipeline must stay up for the duration; a dropped stream is unrecoverable.
  • Consistency: chat is best-effort ordered; video is a continuous timeline.
  • Scale: one source, millions of simultaneous sinks — extreme fan-out from a single origin.

Scale estimation

Assume the final peaks at 5M concurrent viewers at ~4 Mbps average (ABR-adjusted) = 5M × 4 Mbps = 20 Tbps of egress from a single live source — pure fan-out, no long-tail to spread it. As with VOD this must ride the CDN, but now segments are generated live, seconds before they're requested, so the edge can only be warmed segment-by-segment as the stream produces them.

Chat: 500k concurrent chatters, and during a clutch moment say 50,000 messages/second on one channel. Each message must fan out to up to 5M viewers — 50k msgs/s × 5M ≈ an impossible 250 billion deliveries/second if naive. That number forces chat to not deliver every message to everyone: sampling, rate-limiting, and room sharding (below).

Ingest is tiny — one broadcaster, one upstream stream at maybe 8 Mbps. The asymmetry (one in, five million out) defines the whole design.

API sketch

RTMP/SRT ingest  rtmp://ingest/{stream_key}      → broadcaster pushes live
GET  /live/{channel}/manifest                     → live ABR manifest (rolling window)
GET  /cdn/{channel}/{rendition}/seg_{n}.ts        → live segment (edge)
WS   /chat/{channel}                              → join chat room (send/receive)

Solutioning

The video pipeline mirrors VOD but runs online and continuously: the broadcaster pushes to an ingest server (RTMP/SRT), which passes the stream to real-time transcoders producing renditions segment-by-segment (short, ~2s segments to keep latency low). Each new segment is published and immediately distributed to edges; the live manifest is a rolling window of the most recent segments. Viewers pull via HLS/DASH from the nearest edge, exactly like VOD — the difference is that segment N doesn't exist until ~2 seconds ago, so you warm the edge as you produce, not before. The reframing: VOD pre-positions content; live races content to the edge just ahead of demand. The latency floor is set by segment duration and buffering; shrinking segments lowers latency but raises overhead, and truly interactive latency (sub-second) needs WebRTC instead of chunked HLS — a real fork discussed in the LLD.

Chat is the second system, and it's a fan-out problem on its own. The reframing: you cannot deliver 50k messages/second to 5M viewers each; you must reduce fan-out, not brute-force it. The channel's chat is sharded across many chat servers, viewers connect to whichever shard, and messages are broadcast within the room via pub/sub. At extreme scale you additionally rate-limit per user (slow mode) and, for the largest channels, sample or batch messages shown so the human-readable scroll stays legible anyway — nobody can read 50k messages/second, so delivering all of them is both impossible and pointless.

DVR/VOD is a byproduct: the same live segments are retained and, after the stream ends, assembled into a VOD manifest served by the OTT path. The files below detail the live pipeline, the latency fork, and chat fan-out.