Design Live Comments
Live comments are short messages that viewers of a live stream send and see together while the stream runs. The worked event holds 10,000,000 viewers at the same time.
The ask
Viewers of a live stream write short comments. Every viewer of that stream sees the comments flow past.
Comments are part of the event, not a record. Late joiners need the flow now, not the whole history.
The streamer and moderators can remove comments and slow the flow. A big moment can flood the channel in seconds.
The video itself belongs to the streaming system. Comments run beside it, on their own path.
Estimate the scale
The worked event holds 10,000,000 viewers at the same time.
In any minute, 1% of viewers comment.
10,000,000 viewers x 1% = 100,000 comments in that minute.
100,000 comments / 60 seconds = about 1,667 comments per second.
The chat system's connection servers hold 100,000 connections each.
10,000,000 viewers / 100,000 connections per server = 100 connection servers.
API and data
The join operation takes a viewer ID and a stream ID. It opens the connection and returns the recent comments.
The send operation takes a stream ID and the comment text. It returns the stored comment with its sequence number.
A comment record holds the stream ID, the author and the text. It also holds the time and its sequence number in the stream.
Sequence numbers order one stream's comments. Two streams never share a sequence.
A mute operation silences one viewer for a set time. Muted viewers can still watch and read.
High-level design
Connection servers hold the viewers' WebSocket connections. A WebSocket is an open connection that carries messages both ways.
A comment service checks and stores each comment. It assigns the sequence number for the stream.
Delivery fans out from the comment service to the connection servers. Each server forwards only to its own viewers of that stream.
A queue carries comments between the service and the servers. A slow server falls behind in its queue, not in everyone's path.
How a comment travels
A viewer sends a comment on the open connection. The connection server passes it to the comment service.
Checks run first. Length, rate and blocked words are checked before anything fans out.
The stored comment goes out to every connection server holding that stream's viewers. Each server writes it to its viewers' connections.
Viewers see the same order. The sequence number lets a reconnecting viewer spot a gap and ask for the missing comments.
The sender sees the comment at once. A local echo shows it before the fan-out returns it.
Deep dive: the fan-out burst
One comment can reach 10,000,000 viewers. Delivery, not writing, is the cost of this system.
A goal or a big moment lifts comments far above the average minute. The burst arrives with no warning and lasts seconds.
Servers bundle comments for a fraction of a second before sending. One bundle replaces many small writes on each connection.
When a server falls behind, it drops the oldest bundled comments for that viewer. The flow stays live instead of lagging further behind.
Viewer counts and comment rates guide shedding. Smaller streams keep full delivery while the biggest stream sheds first.
Deep dive: moderation under fire
Filters read each comment before it fans out. A filter is a component that takes the comment and returns a verdict.
Slow mode limits one viewer to one comment per set gap. The gap is a setting the streamer controls.
Moderators can delete a comment that already went out. A delete message follows the same fan-out path and removes it from screens.
A flood of abuse can switch a stream to approved-only comments. Volume drops, and the event keeps its channel.
Catching up and leaving
A viewer who reconnects asks for comments after the last sequence number seen. The service keeps a short recent history per stream for this.
History is short by design. After the event, a saved replay can carry the comments recorded with it.
Leaving needs no operation. A closed connection frees its slot on the server at once.
Evaluation and trade-offs
Bundling trades a fraction of a second of delay for far fewer writes. Live comments tolerate that delay, and they do not tolerate falling behind.
Dropping under overload trades completeness for liveness. Each viewer loses some comments so the flow itself survives.
Per-stream ordering trades global order for scale. Nobody needs one order across different streams.
Connection servers are the fleet to size. The worked event needs 100 of them before any comment is even sent.
Live comments in numbers
| Item | Figure |
|---|---|
| Viewers at once | 10,000,000 |
| Viewers who comment in a minute | 1% |
| Comments a minute | 100,000 |
| Comments a second | 1,667 |
| Connections per server | 100,000 |
| Connection servers | 100 |
Exercise
How many connection servers does the worked event need?