Think of Facebook Live like a global radio broadcast tower - except you need one per broadcaster, you do not know when or where any broadcast will start, and you need to simultaneously retune the signal to dozens of different quality levels for listeners on different hardware. One broadcaster starts streaming from a phone in Mumbai. Within 5 seconds, a million viewers in New York, London, and Tokyo should all be watching, each receiving the highest quality their network can sustain, with no rebuffering.

The numbers make this hard: a single 1080p live stream is about 6 Mbps. Scale that to 1 million concurrent viewers and you need 6 Tbps of outbound bandwidth - just for one popular stream. Multiply by thousands of concurrent streams running simultaneously on the platform. Then add the constraint that every viewer must receive an uninterrupted experience regardless of whether their connection is 4G cellular or gigabit fiber.

The three-way tension: latency vs compatibility vs cost. WebRTC gives you sub-second latency but limited scalability past a few thousand concurrent viewers per relay. HLS is compatible with every device on earth but adds 10-30 seconds of latency by default. Low-latency HLS (LL-HLS) sits in the middle: 3-5 seconds of latency with broad compatibility. Choosing the wrong point on this curve means either building a second distribution system or disappointing 99% of viewers.

Requirements and Constraints

Functional Requirements

• Accept live video streams from broadcasters using RTMP from OBS, mobile apps, or streaming software
• Transcode each ingest stream into 4 bitrate tiers in real time (360p, 480p, 720p, 1080p)
• Deliver adaptive bitrate (ABR) streams to viewers using HLS or LL-HLS
• Support millions of concurrent viewers per stream
• Allow viewers to start watching within 5 seconds of a stream going live (join latency)
• Provide stream health monitoring and alerting for broadcasters

Non-Functional Requirements

• End-to-end latency: under 5 seconds (glass-to-glass, broadcaster camera to viewer screen)
• Viewer join latency: under 3 seconds from page load to first frame
• Concurrent viewers per stream: up to 5 million for major events
• Concurrent live streams platform-wide: up to 500,000 streams at any given time
• Transcode latency: each 2-second HLS segment ready within 3 seconds of capture
• Ingest uptime: 99.99% (4 minutes of downtime per month)
• Segment availability at edge: 99.999% (viewer never sees a 404 for a valid segment)

Constraints

• Broadcasters use commodity hardware and unreliable networks - the ingest protocol must tolerate packet loss
• Viewers span every device from 2016 iPhones to 8K smart TVs - delivery must use open standards
• Transcoding is CPU-intensive: one 1080p-to-4-quality-level transcode requires ~8 vCPUs in real time
• Storage cost: segments expire after 24 hours (live replay window), then archival
• A broadcaster with 10 million followers creates a viewer surge at stream start

High-Level Architecture

The system has three horizontal layers: ingest, processing, and distribution. Each layer is independently scaled and can fail in isolation without taking down the others.

The Ingest Layer receives RTMP connections from broadcasters. An ingest edge server terminates the RTMP session and writes raw video segments to a durable intermediate store (Kafka or object storage). The Processing Layer picks up raw segments, runs parallel transcoding workers that produce 4 HLS renditions per segment, and writes finished segments to the segment object store. The Distribution Layer consists of globally distributed CDN Points of Presence (PoPs) that cache HLS segments close to viewers, warm the cache proactively when a new stream starts, and serve HLS manifests and segment files at scale.

RTMP Ingest Layer

RTMP (Real-Time Messaging Protocol) is the industry standard for live stream ingest - it was originally a Flash protocol but became the de facto broadcaster-to-server protocol because every streaming tool (OBS, Streamlabs, FFmpeg) supports it natively.

A broadcaster opens a persistent TCP connection to the nearest ingest server using a URL like rtmp://live.facebook.com/live/{stream_key}. RTMP uses a multiplexed chunk stream over TCP, breaking the video into 128-byte chunks that interleave audio and video data. TCP provides reliable in-order delivery, which prevents the partial-frame corruption that would happen over UDP - at the cost of head-of-line blocking when a packet is lost on a congested network.

Ingest Session Management:

Each ingest server manages thousands of concurrent broadcaster TCP connections. When a broadcaster connects, the ingest server:

1. Validates the stream key against the auth service
2. Creates a stream session record in the session store (Redis) with state LIVE
3. Begins buffering incoming RTMP chunks into a circular buffer (4 seconds, ~4MB per stream)
4. Segments the stream into 2-second chunks as keyframes arrive (IDR frames force a clean cut point)
5. Writes each raw segment to Kafka for the transcoding workers to consume

The ingest server does NOT transcode - it only repackages RTMP into transport stream (TS) segments. This keeps the ingest server lightweight: each box can handle 3,000+ concurrent broadcaster streams. Transcoding happens downstream with dedicated GPU/CPU resources.

Ingest Redundancy: