System Design

Live Streaming

Design a live video broadcasting platform like Twitch or YouTube Live.

Functional requirements

• A broadcaster goes live by pushing one video feed from streaming software or a phone to the platform (e.g., an RTMP or SRT push to their stream key) and can stop at any time.
• Any number of viewers can watch a live channel in a browser or app, with the player switching between quality levels (e.g., 1080p, 720p, 480p) as their bandwidth changes.
• A viewer joining mid-stream starts playing within a few seconds and sees the broadcast only a few seconds behind real time.
• Viewers can see which of the channels they follow are live right now, along with an approximate live viewer count.
• If the broadcaster's connection drops briefly, the channel stays live and resumes when they reconnect within a grace period (e.g., 60 seconds) instead of ending the broadcast.

Non-functional requirements

• Glass-to-glass latency under 8s at p99 on the standard path and under 3s for channels that opt into low-latency mode; join time (click to first frame) under 3s at p99.
• Availability over consistency: viewer counts and the live-now list may be seconds stale, but a viewer must never get segments from the wrong channel or out of order, and a channel must never look ended while its broadcaster is still sending.
• Segments are ephemeral: they need only outlive the broadcast by a couple of minutes for late joiners; stream session records (start, end, peak viewers) are durable.
• Audience size never touches the broadcaster: going from 100 to 5M viewers within a minute must not add ingest latency, drop frames, or interrupt the stream.
• Stream keys are secrets: only the key holder can publish to a channel and a leaked key can be rotated instantly; playback URLs cannot be turned into a way to publish.

Scaling & constraints

• 3M broadcasters go live each month; ~150K channels are live at once at the daily peak, with ~10M concurrent viewers (15M during major events).
• Ingest is 3-8 Mbps per channel (a 1080p60 source), ~1 Tbps at peak; each channel is transcoded live into a 5-rung ladder (1080p down to 160p) costing ~1-2 CPU cores or a slice of a GPU.
• Egress dwarfs ingest: 10M viewers at ~3 Mbps ≈ 30 Tbps; the top 1% of channels draw ~80% of viewers and the median channel has under 5.
• A raid or breaking-news moment can take one channel from 100 to 5M viewers in 60 seconds; with 2-second segments across 5 rungs, each channel emits ~150 new objects per minute.
• Broadcaster connections are flaky: ~5% of broadcasts have at least one ingest disconnect, typical gaps are 2-20 seconds, and upload bandwidth swings 2x within a session.
• Segments are kept for a 2-minute DVR window then dropped; session metadata (~1 KB, ~2M sessions/day) is kept 2 years; viewer counts need refreshing only every ~10 seconds.

Out of scope

• Chat, reactions, and moderation tools.
• Recording broadcasts as on-demand videos, clips, and highlights.
• Monetization, subscriptions, and ad insertion.
• Discovery, search, and recommendations beyond the followed-channels live list.