Live Comments for Live Video (Facebook Live / TikTok Live)

0) Problem Restatement

Design the comments feature for live video. While a live stream is playing, viewers post short comments, and everyone watching sees new comments appear within about a second. A popular stream can have millions of viewers, and one viewer's comment must reach all of them.

A common variant: comments are tied to a position in the video (like a synchronized overlay), so people watching a replay later see the comments appear at the same moments.

1) Requirements

1.1 Functional

• Post a comment on a live video.
• See new comments in near real time.
• New viewers see recent comments when they join.
• Moderation: filter spam and abuse, let the host delete comments and block users.
• (Variant) Replay comments in sync with video playback.

1.2 Non-Functional

• Low latency: under ~1–2 seconds from post to display.
• Huge fan-out: one message → millions of screens.
• Scalable for many streams at once, most of them small.
• Graceful: during huge events it is fine to show a sample of comments, but the system must not fall over.

1.3 Scale Estimates

• 1M concurrent live streams, most with fewer than 100 viewers.
• A top stream: 5M viewers posting 10K comments/sec. Delivering every comment to everyone would mean 50 billion deliveries per second, which is impossible. We must sample.
• Each WebSocket server holds ~100K connections, so 5M viewers need ~50 servers for that one stream.

1.4 API Design

• POST /v1/videos/{id}/comments { text, video_ts_ms? } → { comment_id }
• WebSocket /v1/videos/{id}/live → server pushes { comment_id, user, text, ts }
• GET /v1/videos/{id}/comments?from_ts=&to_ts= (recent history and replay)

2) High-Level Architecture

2.1 Overview

• Comment Service: validates, checks rate limits and moderation, stores the comment, and publishes it.
• Moderation: quick filters (blocked words, spam checks) inline, and heavier ML checks async.
• Pub/Sub (Redis pub/sub, Kafka or a dedicated fan-out tier): a channel per video.
• Gateway / WebSocket servers: hold viewer connections. Each server subscribes only to the video channels its viewers are watching.
• Comment store: Cassandra/DynamoDB, keyed by video and time.

2.2 Architecture Diagram

flowchart LR
    V1["Viewer posting"] --> CS["Comment Service - rate limit, moderation"]
    CS --> DB[("Comments DB - by video, time")]
    CS -->|"publish video:123"| PS[("Pub/Sub - channel per video")]
    PS --> G1["WebSocket server 1"]
    PS --> G2["WebSocket server 2"]
    PS --> G3["WebSocket server N"]
    G1 --> A["Viewers"]
    G2 --> B["Viewers"]
    G3 --> C["Viewers"]

3) Data Model

comments:
  video_id (partition key), ts_bucket (e.g., minute), comment_id (time-ordered),
  user_id, text, video_ts_ms, status (visible/removed)

Partitioning by video and time bucket keeps "recent comments for this video" and "comments between minute 12 and 13" fast.

4) Key Flows

4.1 Posting and delivering

1. A viewer posts. The service applies a rate limit (e.g., 1 comment per 2 seconds per user) and runs fast moderation.
2. It stores the comment, then publishes it to channel video:{id}.
3. Every WebSocket server subscribed to that channel receives it once, then pushes it to all its local viewers of that video.

This two-level fan-out is the key. Pub/sub sends to ~50 servers, and each server sends to ~100K local connections. No single machine talks to millions of viewers.

4.2 Joining a stream

The client opens a WebSocket, and its server subscribes to the video channel if it isn't already. The client also loads the last ~50 comments from the store so the screen isn't empty.

5) Deep Dive A — Huge streams

• Sampling: nobody can read 10K comments/sec. Each WebSocket server sends each viewer at most ~10 comments/sec, choosing by rules (comments from friends, the host and verified users first, then a random sample).
• Aggregate reactions: likes and hearts are counted and sent as totals every second, not one message per like.
• Batching: send comments in small batches every 200–500 ms instead of one message each.
• Separate hot streams: route very popular streams to a dedicated fan-out cluster so they don't affect small streams.

6) Deep Dive B — Syncing with video time (replays)

For overlays pinned to the video timeline, store video_ts_ms (the playback position when the comment was posted).

• Live: show comments as they arrive.
• Replay: the player requests comments in windows (e.g., the next 30 seconds of video time) and shows each one when playback reaches its video_ts_ms. Seeking just loads a different window.
• Pre-compute a sampled "highlight" set for very busy videos, so replays don't fetch millions of comments.

7) Trade-offs & Alternatives

8) Common Follow-up Questions

• "How do you delete a comment already sent?" Publish a "remove comment_id" event on the same channel, and clients hide it.
• "Ordering?" Order per video by server timestamp. Small reordering is acceptable for comments.
• "Multi-region?" Each region has its own WebSocket servers. Publish comments to a global bus (or replicate channels across regions), so every region's servers receive them.

9) Wrap-Up

Store each comment and publish it to a per-video pub/sub channel. WebSocket servers subscribe to the channels their viewers watch and fan out locally. That two-level fan-out scales to millions of viewers. For huge streams, sample and batch comments per viewer and aggregate reactions, and for replays, store the video timestamp so comments reappear in sync with playback.