Design Facebook Live Comments: Real-Time Fan-Out to Millions

The feature set is intentionally narrow. Anyone watching a broadcast can type a comment on it. Everyone watching that video sees new comments show up within seconds, with no page refresh. And a viewer who tunes in partway through can scroll back to read what was said earlier, page by page.

Those three requirements map onto three distinct paths: a write path for posting, a push path for live delivery, and a read path for history. Treating them separately is what allows each to scale in its own way. Threaded replies, emoji reactions and moderation are valuable features, but each adds its own complexity and none of them changes the core delivery problem, so they are parked for this discussion.

Latency is what makes the feature feel live. If a comment takes more than about two seconds to reach other viewers, people end up reacting to moments that have already passed and the conversation stops making sense. Fan-out is the second pressure: a single major broadcast, such as a cricket final, may have millions of concurrent viewers all waiting on the same stream of comments.

Availability outranks strict consistency here. A viewer seeing a comment a moment late, or occasionally not at all, is a minor blemish; the comment panel going dark during a big event is a headline. That choice gives us permission to use best-effort delivery on the live path. Finally, the system must run hundreds of thousands of broadcasts concurrently, so every component needs to scale out horizontally.

Assume about 1 billion comments per day across every live video, which averages roughly 12,000 writes per second. Any reasonably sized distributed database absorbs that without strain. At about 500 bytes per comment, storage grows around 500 GB a day, again comfortable.

The worrying figure is fan-out. Take one broadcast with 1 million viewers receiving 100 comments per second: that is 100 million individual deliveries per second for a single video. So the estimate clearly says the write side is routine and nearly all design attention belongs on delivery. Every later decision, from transport to routing to batching, aims at shrinking or distributing that multiplication.

The data model stays small: a live broadcast, the comments attached to it, and the people who author or follow them. Posting uses POST /videos/{id}/comments with the text and returns a comment ID plus timestamp, which the client can use to show its own comment immediately.

History is fetched with GET /videos/{id}/comments?before= using a cursor, returning a page of older comments and the next cursor. Cursors work better than offsets here because new comments are constantly arriving, which would shift offset-based pages. Live delivery uses GET /videos/{id}/comments/stream, a long-lived SSE connection on which the server keeps sending each new comment as it lands.

A posted comment travels through a load balancer to a comment service that validates it and persists it to a comments database such as Cassandra. The partition key is the video ID and rows sort by time, so loading the latest page for a late joiner is a single partition read.

After storing the comment, the service publishes it to a pub/sub channel dedicated to that video, for example on Redis pub/sub. Crucially, the comment service has no idea who is watching. It writes once and announces once, keeping the posting path fast and independent of audience size.

Realtime servers hold the open viewer connections. Each one listens only on channels for videos its connected viewers are watching. When a comment arrives on a channel, the server writes it to every local connection for that video, so a single publish can reach thousands of people on one machine. Storage happens once on the write side, and multiplication happens only at the edge where it is unavoidable.

Polling every few seconds is easy to build and works through any network, but with millions of viewers it produces a torrent of mostly empty requests and still feels sluggish. WebSockets give a persistent, bidirectional, low-latency pipe, yet this feature mostly needs data moving in one direction, and WebSocket upgrades require extra attention at proxies and load balancers.

Server-sent events fit the shape of the traffic best. The server streams comments over an ordinary long-lived HTTP response, and browsers handle reconnection automatically. Since a viewer posts far less often than they read, posting remains a regular POST routed through the normal load balancer, while SSE carries only inbound comments.

Reconnection is handled gracefully through Last-Event-ID. When a connection drops and the browser reconnects, it sends the ID of the last comment it saw, and the server can replay anything newer from storage so the viewer does not end up with a gap.

The core question is how one comment reaches viewers scattered across hundreds of realtime servers. The flow begins with a viewer whose SSE connection is assigned to one particular realtime server. That server joins the channel named after the video, such as video:{id}, exactly once, regardless of whether one or ten thousand of its viewers are watching that broadcast.

When a comment is posted, the comment service publishes it to that single channel and moves on. Each listening server receives one copy and loops over its own local connections to deliver it. This two-level fan-out keeps the broker's work proportional to servers, not viewers.

Routing makes it more efficient still. The load balancer uses consistent hashing on the video ID, so viewers of the same broadcast cluster onto a small group of servers. Fewer servers then listen on each channel, and every message is useful to many local viewers. The pub/sub cluster is also sharded by video ID, so no single broker has to carry every broadcast.

A stream with ten million viewers needs extra tactics. Batching is the first: rather than emitting one message per comment, each realtime server collects comments for a few hundred milliseconds and sends them as one bundle. Viewers notice no difference, but message count and per-message overhead drop sharply.

Sampling is the second. Nobody can read a thousand comments a second, so for very large broadcasts the server sends a ranked subset, favouring friends, highly liked comments and verified accounts. A relay tier adds structure to fan-out: the broker hands every comment to a handful of regional relays, which pass it along to edge servers in their region, so a comment crosses each long-distance link only once. Finally, per-user rate limits and spam filtering protect the write path from floods during big moments.

SSE keeps one-directional push simple, while WebSockets earn their extra complexity only when the product genuinely needs two-way messaging such as full chat. Redis pub/sub is lightweight and quick but fire-and-forget, so a disconnected listener simply misses messages; Kafka offers durability and replay at the cost of more weight and latency.

Sampling cuts load and visual noise dramatically, but it means not every viewer sees every comment, which is a product decision as much as a technical one. The guiding principle is best-effort live delivery backed by durable history. A missed push is tolerable because the database remains the source of truth and fills gaps on reconnect or scroll. In short: persist each comment once, fan out per video, and batch and sample when a broadcast gets huge.