Live comments (Facebook Live)

01 · CONTEXT AND REQUIREMENTS

What live comments need to do

Live comments let people watching a broadcast write and read messages while the video is happening. The source's functional requirements are three: post comments on a live video, see new comments while watching, and see comments made before joining the broadcast.

The non-functional requirements drive the design: scale to millions of simultaneous videos and thousands of comments per second on each video, prioritize disponibilidade over consistency (eventual consistency is enough) and deliver in near real time, under 200 ms end to end under typical network conditions. The source explains the target: interactions under 200 ms are generally perceived as real time.

02 · API AND STORAGE

Writing and paginating the history

Creation is a endpoint simple POST. The commenter's identifier does not go in the request body: it comes from the header, via a session token or JWT. The comment management service receives the message and writes it to the database, which in the source is DynamoDB.

1. The commenter sends the message to the comment management service.

2. The service writes the comment to the database.

3. The viewer queries the service to read comments.

For history, someone joining a video sees the recent comments and scrolls up to see older ones. This calls for pagination. Offset pagination is unstable on a moving queue: if a comment is inserted or removed during scrolling, the offset becomes wrong and duplicates or gaps appear. Cursor pagination uses a cursor as the starting point, and the source considers it more suitable here. Even so, it still requires a database query for each new page.

03 · FROM POLLING TO PUSH

How to deliver new comments

The most naive approach is for clients to ask for new comments every few seconds. It pressures the database and generates many unnecessary requests. The alternative is communication protocols that follow a push model, in which the server sends the comment to the client as soon as it is created, using WebSockets or Server-Sent Events (SSE).

04 · SCALING TO MILLIONS

Coordinating several messaging servers

With SSE, each viewer holds an open connection. A server can handle many connections, on the order of 100 thousand according to the source, but CPU, memory and file descriptors become bottlenecks before the theoretical limit. For many millions of viewers you need to scale horizontally, adding servers.

This creates the coordination problem: viewers of the same video may be connected to different servers, and the server that receives a comment cannot send it to someone connected to another. The source separates write traffic from read traffic, creating real-time messaging servers that send the comments to viewers. Since write traffic is much smaller, they scale independently.

1. The commenter sends the comment to the service, which writes it to the database.

2. The service publishes the comment to the pub/sub channel.

3. The messaging servers subscribe to the channel and receive the comment.

4. Each server sends the comment over SSE to the viewers connected to it, even if they belong to different servers.

No pub/sub in its naive form, the service publishes to a channel that all messaging servers subscribe to, and each server processes all the comments of all videos, even without viewers for that video. The partitioned version uses a hash function to distribute videos across a limited number of channels, and each server subscribes only to the channels it needs. With round robin, a server could end up subscribing to many channels; for that reason the source proposes a balanceador that uses consistent hashing on the video identifier to send viewers of the same video to the same server.

The alternative is the Dispatcher: a service that routes each comment directly to the correct messaging servers, instead of the servers subscribing to channels. It keeps a dynamic map of which servers handle which videos, updated by heartbeats and by registration.

05 · MEGA-STREAMS

When a video's audience explodes

When comments arrive very fast, the traditional real-time goals, low latency and reliable delivery of every message, matter less, because viewers only need to see enough comments to feel the energy of the crowd.

The source's first answer is sampling: deliver only a subset of the stream to each viewer. As an example, it suggests sampling 50% of comments at 100 per second and only 1-2% at 5,000 per second. Even so, persistent SSE connections with millions of viewers remain.

The second is to swap push for a pull model that uses the CDN that already exists. A circular buffer holds the recent comments of each mega-stream, and every second or less a snapshot is written to Redis or to the CDN origin. The CDN distributes the snapshot globally, cached at the edges, and clients poll it every second.

1. The service receives the comments and maintains a circular buffer with the video's most recent ones.

2. Periodically, a snapshot of the buffer goes to Redis or to the CDN origin, and the CDN distributes it, cached at the edges.

3. Viewers fetch the latest snapshot from the CDN instead of holding an SSE connection.

4. The client animates the new comments, spacing them out over the interval instead of dumping them all at once.

The cost is latency: up to 1-2 seconds of delay instead of under 200 ms. There are two subtleties. Reading your own comment is handled locally by the client, with optimistic insertion. And the switch of mode is automatic above 100 thousand simultaneous viewers or 500 comments per second, which requires hysteresis on the threshold to avoid oscillating between modes.

06 · DISCONNECTIONS

Not losing comments on mobile networks

Ignoring disconnections is the simplest option, but the viewer loses all the comments posted during the drop. SSE has its own reconnection mechanism, the Last-Event-ID header: each comment sent carries a unique event ID, and upon seeing the header on reconnection the server resends the missed comments before returning to the normal flow.

The source adds some cautions: the client can store the last ID locally and request recovery over HTTP; practical limits must be set on how far back to resend; a shared Redis cache lets any server resend recent comments if the viewer reconnects to another; and the client must deduplicate by ID when comments arrive over SSE during recovery over HTTP.