Live Comments

What the interviewer is asking

"Design live comments" means the feed under a live video on Facebook Live or YouTube Live: comments scroll past while hearts float up, and a big stream has millions watching at once. It looks like chat, but it's the opposite shape. Chat delivers each message to one person or a small group and tracks every delivery; here one stream goes to millions of viewers, everyone gets the same comments, and nothing is stored per viewer.

The hard part is the fan-out: one comment has to reach every screen watching within a couple of seconds, and the numbers show that showing every comment to everyone is impossible. The walkthrough follows the 8 steps of the interview framework: scope, data, API, the busy path, numbers, services, scale and deep dives.

1. Scope: what version 1 must do

• See new comments on the video you're watching within a couple of seconds.
• Post a comment on the live video.
• Hearts: tap a heart and see a live count of everyone's hearts.

Park the rest out loud, one line each: replies in threads, moderation queues where people review flagged comments, a "top comments" list ranked by likes, and replaying the comments with the video after the stream ends. Saving every comment now keeps replays possible. And "within a couple of seconds" matters: it leaves room to batch and pick comments.

2. Data: one record per comment, nothing per viewer

record    fields
comment   id, video_id, author_id, text, time
viewer    nothing stored: just an open connection

Comments are read by video, oldest to newest, so key them by video id and time, and split the table by video id when it grows. Everyone watching sees the same comments, so one copy of each is enough.

The empty row is the point. In chat each message waits for its recipient and gets a ✓✓. Here nothing waits: a viewer who joins late, or whose connection drops, just picks up the stream from now.

3. The API: a POST and a stream

POST /videos/v42/comments   {"text": "Liftoff!"}
  → 201 Created   {"id": "c901"}

POST /videos/v42/hearts
  → 202 Accepted

GET /videos/v42/comments/stream   Accept: text/event-stream
  → 200 OK, and the answer stays open:
data: {"id": "c901", "user": "Ana", "text": "Liftoff!"}
data: {"id": "c902", "user": "Ben", "text": "Goosebumps"}

Posting is rare, so it's a plain POST. Viewers mostly listen, so each one opens a server-sent events stream: one HTTP request whose answer never ends, each new comment written into it as it happens. It's plain HTTP, and the browser reconnects on its own. A WebSocket works too (the Real-Time Updates lesson compares them); the rest of the design doesn't change.

Two answers to avoid. Polling every 2 seconds makes a million viewers send 500,000 requests a second just to ask. Push notifications go through Apple's or Google's push service to wake up apps that aren't open; they can arrive late and aren't made for a message every second.

4. The busy path: one comment to everyone watching

1. Ana's app sends POST /videos/v42/comments with "Liftoff!".
2. The server saves the comment in the comments database.
3. The server finds every open stream watching v42.
4. It writes the comment into each of those streams.
5. Each viewer's app shows "Liftoff!" under the video.

Save first, then send: once stored, the comment can't be lost. Ana's own app shows it at once, without waiting for the stream. The first half is one write, whatever the audience; the second half, the fan-out, grows with every viewer.

5. The numbers

From the interviewer: a big stream has 5 million viewers, and at its peak they post 2,000 comments a second. Say one connection server holds about 100,000 open connections, the number from Real-Time Updates.

deliveries   5 million viewers × 2,000 comments = 10 billion a second
per viewer   2,000 comments a second, far more than anyone can read
servers      5 million ÷ 100,000 = 50 connection servers, plus spares
per server   100,000 viewers × 2,000 comments = 200 million messages a second

Two conclusions shape the rest: delivery is spread over many servers that each need every comment of the video, and not every comment can be shown to everyone.

6. Services: connection servers and a comment service

• Connection servers hold the viewers' streams, about 100,000 each, write new comments into them and notice when a stream closes.
• The comment service checks each comment (its length, and a rate limit per person as in the Rate Limiting lesson, so one bot can't flood the feed), gives it an id, saves it and hands it on once for delivery.

Connection servers are sized by viewers: 50 for this video. The comment service is sized by comments, 2,000 a second at the peak, a few servers' work, and restarting it drops no viewer's stream.

7. Scale: a pub/sub channel per video

The comment service has saved c901 and must reach exactly the 50 connection servers holding viewers of v42. The Chat way, looking up each recipient's server in a session store, costs 5 million lookups per comment: 10 billion a second. A load balancer can't help either: it only spreads the requests clients send it and keeps no list of who's watching what.

The fix is a pub/sub channel per video, as in the Pub/Sub and Streams lesson. Each connection server with viewers of v42 subscribes to v42's channel; the comment service publishes each comment once, and the channel gives one copy to every subscriber. At 2,000 comments a second that's 100,000 copies a second, and the comment service never needs to know who's watching, or where.

8. Deep dive: fan-out through connection servers

Follow one comment through 3 connection servers. Servers 1 and 2 hold viewers of v42; Server 3 holds only viewers of v7, another live video:

server     viewers                  v42's channel   copies of c901
Server 1   Ben, Cy, Dee: v42        subscribed      3 viewers
Server 2   Eli, Fay: v42; Gus: v7   subscribed      2 viewers (not Gus)
Server 3   Hal, Ivy: v7             not             none

The comment service publishes 1 copy, the channel sends 2, and 5 viewers see it. At full size: 1 from the comment service, 50 from the channel and 5 million to viewers, spread over 50 servers.

Who watches what decides the subscriptions. Each connection server counts its viewers of each video: when a count goes from 0 to 1 it subscribes to that video's channel, and when it drops back to 0 it unsubscribes. When Eli and Fay close v42, Server 2's count drops from 2 to 0, so it unsubscribes from v42 and stays on v7's channel for Gus. A hot video ends up on all 50 servers and a small one on a few: the copies follow the viewers. A common refinement sends viewers of the same video to the same servers (by video id), so a small stream isn't spread thin.

9. Deep dive: too many comments to show

Each of v42's 50 servers gets all 2,000 comments a second, and no one can read that. Say the app shows at most 10 a second. Which 10?

• The first 10 each second: whoever posts fastest wins, so bots and copy-pasted spam fill the start of every second.
• A random 10: fair and cheap, but each comment reaches a viewer with a chance of 10 in 2,000, 1 in 200, so a friend's comment almost never would.
• Friends first, then the best-rated: each comment gets a rating when it's posted (spam and repeats rate low). This is the usual answer.

Run it small: one second with 30 comments for Ben, who sees at most 10.

step            comments
friends first   Cy's (rated 4) and Dee's (rated 3), whatever their rating
best-rated      the 8 best of the other 28: three 9s, two 8s, three 7s
not shown       the 20 others, all rated 6 or lower

Pick on the connection server, the only part that knows who's watching on it: the best-rated once per video each second for all its viewers, then each viewer's friends. Each server sends about 1 million messages a second instead of 200 million, and the video 5 million × 10 = 50 million instead of 10 billion: 200 times fewer. The comment service can't pick per viewer (Ben's friends aren't Eli's), though it can drop spam once for everyone, and hiding comments in the app would keep the 10 billion. The 1,990 a second Ben doesn't see are still saved for the replay. Picking once a second adds at most a second of delay, inside the couple of seconds agreed in scope.

10. Deep dive: reactions as counts

In one busy second, 12,345 hearts arrive for v42. Published like comments, they'd make about 60 billion deliveries a second, 6 times the comments' problem, for taps with no text. Letting apps fetch a stored total every second is no better: 5 million requests a second for one number, and 12,345 writes a second to one row, more than one row takes (about 5,000 a second: the hot row of Distributed Counter).

A heart only says "one more", so send a count. A heart counter keeps a tally per video in memory; every second it publishes one message, such as "+7 hearts" after a quiet second of 7 taps, to the video's channel and starts again at 0. Each viewer gets one small update a second, 5 million in all, whatever the number of taps, and the app floats that many hearts. The counter also adds each tally to the video's total in the database, one write a second: Distributed Counter's batching. With several counter servers, each publishes its own tally and the apps add them up.

What breaks first

• A connection server crashes: its 100,000 viewers reconnect at once. Apps wait a random second or two first, so the load spreads, and since nothing is stored per viewer there's nothing to catch up on.
• A sudden rush into one stream: each extra connection server subscribes once, so the channel's copies grow by one per server, not one per viewer.
• The pub/sub system: thousands of live videos each have a channel; split the channels over pub/sub servers by video id.
• Spam and bots: the rate limit per person stops floods, and low ratings keep repeats off everyone's screen.

Summary: the order to follow

1. Scope: comments within a couple of seconds, posting, hearts; park replies, moderation queues, top comments and replays.
2. Data: comments (id, video, author, text, time); nothing per viewer.
3. API: POST /videos/{id}/comments, and a server-sent events stream per viewer.
4. Busy path: one comment, saved once, written to everyone watching.
5. Numbers: 10 billion deliveries a second; 50 connection servers for one video.
6. Services: connection servers hold streams; a comment service checks, saves and publishes.
7. Scale: a pub/sub channel per video.
8. Deep dives: publish once and copy per server, subscribing while a server has viewers; at most 10 comments a second per viewer, friends first; hearts as one count a second.

Chat finds each recipient; live comments broadcast one stream to everyone watching. Publish once per video, and let the copies multiply close to the viewers.