01Who can post, and does the author see their own comment instantly?
Any viewer can post; the write is acked in one round trip and the author sees their own comment immediately via local echo, whatever sampling later decides.
Premium preview
Live Comments
Design a live comments system that fans out comments from one live event to millions of concurrent viewers in real time.
00
Practice checkpoints
The requirements are open as a taste. From the numbers onward, the full guide opens in the app.
- 01Clarify scope
- 02Requirements + scale
- 03API + data modelUnlocks in the app
- 04Draw architectureUnlocks in the app
- 05Deep diveUnlocks in the app
- 06Trade-off decisionUnlocks in the app
01
Requirements that shape the design
Do not only state requirements. Ask for them. Each card pairs the design constraint with a clarification question you can say out loud before drawing the architecture.
Functional requirements
02Is this one room with millions of viewers, or millions of small rooms?
One room: a comment posted to a live stream fans out to every concurrent viewer of that stream — publish once, deliver millions of times. This is broadcast, not chat.
03During a spike, does every viewer receive all 17,000 comments a second?
No — each viewer receives a sampled, rate-shaped stream capped near 20 comments a second, because nobody can read a firehose; sampling is the product, not a failure.
04I join 40 minutes in — is my comment feed blank?
No — a late joiner is seeded with the last ~50 recent comments as context, then picks up the live tail.
05The creator pins a giveaway — can sampling drop it?
Never — pinned and creator comments ride a priority lane delivered to every viewer; sampling applies only to the crowd.
06A slur slips through — can it be pulled off screens already showing it?
Yes — a moderation takedown propagates as a tombstone through the same fan-out and erases the comment from live screens within about a second.
Out of scopeVideo ingest and delivery itself (the live stream rides a CDN — separate system) · Personalized ranking of which comments each viewer sees (sampling here is heuristic, not ML) · Threaded replies and viewer-to-viewer DMs (that is the Chat Service question)
Non-functional requirements
01How fast must a comment reach other screens?
Under about one second end to end at p95 — live comments are part of the live feeling; a 10-second lag makes the crowd feel canned.
02What is the single biggest audience we must survive?
Five million concurrent WebSockets on ONE stream — the design must scale per stream, not just per platform, because one event can dominate everything.
03Ingest outruns fan-out capacity — what breaks first?
Crowd comments are shed first and connections last: viewers keep a live, thinner stream — the system degrades by showing less, never by dropping the room.
04Do comments need exact global ordering?
No global order — roughly chronological per viewer is enough; a total order across millions of deliveries costs coordination the one-second budget cannot afford.
05What delivery guarantee does a comment get?
Two tiers of delivery: crowd comments are best-effort on the live path, while pinned comments and tombstones are at-least-once with retries — the lanes have different contracts.
Keep asking — the interview is a conversation
Real interviews probe far more than a tidy list. These are the scope questions that separate candidates who interrogate the problem from those who recite it.
- What is the peak concurrent audience on a single stream — thousands, or millions? The architecture changes shape at that boundary.
- Is it acceptable that most viewers never see most comments, as long as the stream feels alive and readable?
- Do pinned and creator messages carry a hard delivery guarantee even while crowd comments are being shed?
- How fast must a moderation takedown clear screens that already rendered the comment — under a second, or best effort?
- Do comments need to outlive the stream for replay and VOD, or die with it?
01
Unlock the full playbook for Live Comments
Numbers, architecture diagram, API and data model, deep dives, expected topics, self-check, whiteboard starter, and common mistakes unlock inside the app.
Numbers that force architecture decisions
Locked in the app
Architecture path
Locked in the app
API and data model
Locked in the app
Deep dive directions
Locked in the app
+Series