Design Twitch

Hard45 min
1 / 30
System design answer

Design Twitch

Hard45 min30 sections
understanding•11 min read

Problem Statement: Interactive Live Streaming at Internet Scale

Frames Twitch as a real-time, fan-out-dominant, chat-coupled video platform rather than a simple content delivery system.

Problem statement

Design an interactive live-streaming platform — the class of product Twitch represents — that lets a broadcaster push a real-time video feed, transcodes it into multiple bitrates, distributes it to millions of concurrent viewers through a CDN, and overlays a real-time chat that every viewer sees within one second of the broadcaster speaking.

This is not a video-on-demand system. Netflix can pre-compute every segment, replicate it globally, and serve it from cache. A live stream has no cacheable content until the segment is produced, and by the time it is replicated the next segment is already being encoded. The system must produce, distribute, and consume video segments at the speed of the broadcast itself.

The second axis that separates this from ordinary video delivery is the chat. Twitch's engineering blog describes the chat system as processing over one billion messages per day, with peak events pushing well beyond that. During a major esports final or a Twitch Rivals event, a single channel can receive 50,000+ chat messages per second. The chat must fan out to every connected viewer in the channel within one second, while the video is being delivered with a glass-to-glass latency under five seconds.

Why this problem is distinctive

A VOD platform's hardest problem is storage and retrieval. A live streaming platform's hardest problem is fan-out under extreme skew. Ninety percent of viewers watch the top one percent of channels. A single channel can go from 200 viewers to two million in minutes when a major streamer goes live or a raid is announced. The architecture must handle this skew without pre-provisioning for every channel at maximum capacity.

The second distinctive property is the coupling between video and chat. Viewers expect to see chat messages that reference what is happening on screen right now. If the video is delayed by five seconds and the chat is delivered instantly, the chat spoils the stream. The system must either synchronize the two or accept a bounded skew and design around it.

The third property is the broadcaster side. The ingest pipeline must accept a single RTMP or WebRTC stream from the broadcaster, transcode it into four to six adaptive bitrate renditions, and make all of them available through the CDN within two seconds. If the ingest server fails mid-stream, the broadcaster must be able to reconnect to a different ingest endpoint and resume within seconds, not minutes.

The four architectural planes

  1. Ingest plane: receives the broadcaster's raw stream, transcodes it, produces HLS or DASH segments, and pushes them to the CDN origin.
  2. Distribution plane: a multi-CDN edge network that serves video segments to viewers with adaptive bitrate switching.
  3. Chat plane: a real-time messaging system that fans out chat messages to all connected viewers in a channel with sub-second latency.
  4. Platform plane: user accounts, channel metadata, subscriptions, bits, donations, moderation, analytics, and monetization.

A strong interview answer keeps these planes separate. The chat plane can degrade without affecting video delivery. The platform plane can be eventually consistent. But the ingest and distribution planes must maintain strict latency and availability guarantees because a dropped stream is a lost audience.

Key Highlights

  • •Live streaming has no pre-computable cache — segments must be produced, distributed, and consumed at broadcast speed.
  • •Chat fan-out is the dominant write workload during peak events, exceeding 50,000 messages per second on a single hot channel.
  • •Viewership is extremely skewed: the top one percent of channels carry the majority of concurrent viewers.
  • •The four planes — ingest, distribution, chat, platform — have different consistency, latency, and availability requirements.
  • •Ingest failover must complete within seconds or the broadcaster loses their audience.
Lead With Fan-Out Skew
State in the first two minutes that the hardest problem is not storing video but fanning out a live stream and chat to a massively skewed viewership distribution. This immediately distinguishes a live streaming design from a VOD design.
Do Not Design a VOD System
A design that pre-computes and caches all content globally is a VOD architecture. Live streaming produces segments in real time and must distribute them before they expire. Starting with a VOD mental model will fail a serious interview.

Section Rescue Kit

Buzzwords to use:

Glass-to-Glass LatencyAdaptive Bitrate Streaming

Safe statements:

  • "I will separate the video delivery path from the chat delivery path because they have fundamentally different fan-out and latency characteristics."
  • "Before choosing technologies, let me define which plane owns which consistency and latency guarantee."
Design Twitch - System Design | WinJob | WinJob