Design Live Video Streaming (Twitch)

Real-Time & CollaborationHarddesign-live-streaming

Design live broadcast at scale: a streamer's RTMP ingest becomes an adaptive ladder delivered to millions of viewers within seconds, with synchronized chat.

Ingest + Transcode LadderHLS/LL-HLS ChunkingEdge FanoutChat Fanout

Traffic & Capacity Estimates:

100k concurrent streams · 20M concurrent viewers · 3-5s glass-to-glass latency

Functional Requirements

•Ingest a live RTMP/SRT stream, transcode to an adaptive bitrate ladder, and segment for delivery.
•Deliver low-latency HLS/DASH segments through the CDN to millions of simultaneous viewers.
•Provide live chat and reaction fanout synchronized loosely with the video timeline.
•Record the broadcast to VOD automatically as it streams.

Non-Functional Requirements

•Glass-to-glass latency of 3-5 seconds; sub-second for interactive modes.
•Player must adapt bitrate without stalls as viewer bandwidth changes.
•A transcoder failure must fail over without dropping the broadcaster's session.

Back-of-the-Envelope Math

20M viewers * 4 Mbps average = 80 Tbps of peak egress — CDN capacity is the dominant constraint and cost.
100k streams * 5 ladder renditions = 500k concurrent transcode jobs, GPU-bound.

Key Architectural Trade-offs

Segment duration is the core latency dial: 2s segments are CDN-friendly and add buffering delay; 200ms LL-HLS parts cut latency and multiply request volume.
Transcode every stream on ingest (predictable, expensive for streams nobody watches) vs transcode on first viewer (cheap, adds startup delay).
Chat fanout to a million viewers needs sampling or room sharding — full fanout of every message to every viewer does not survive contact with a big event.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow