Live Commenting System Design: Hot Broadcasts, Fan-Out, and Moderation Ordering

A live broadcast has 100,000 viewers. Comments arrive faster than anyone can read, a slow connection falls behind, and a moderator removes a comment just before an old publication event reaches another viewer. Live commenting system design becomes useful when you can explain all three failures together.

The central proposal in this guide is to separate durable comment state from the live presentation stream. Preserve comment identity and moderation versions even when the interface samples ordinary comments. The fan-out path must preserve removals when old publication packets arrive late.

Evidence boundary: vendor API and delivery facts below come from official documentation. The architecture, numbers, event trace, and local tests are original design exercises. The public PracHub prompts are candidate-reported practice material, not a guaranteed employer question or a description of any company’s implementation. Start with Design real-time live comments and make its ordering and delivery requirements explicit before drawing servers.

Decide what viewers must actually see

Clarify whether every viewer must receive every accepted comment. For this proposal, the service durably records submissions, moderates them, and presents a bounded live selection during a hot broadcast. A quieter room may show everything. Recent-history queries return currently visible comments under an explicit retention policy, rather than promising an unlimited transcript.

This changes the meaning of success. Accepted means the service stored the submission and assigned its comment ID. Pending means moderation has not approved public display. Published means the comment is eligible for distribution; it does not prove that every viewer rendered it. Removed means later reads and authorized live projections must suppress it.

Show the author a private pending item with its request key. Reconcile that item with the acknowledgment and public echo without making a second bubble. A rejected submission needs an understandable status. It should not appear as a public comment merely because an optimistic component displayed it locally.

Keep private messaging, offline inbox delivery, presence, and full creator tooling outside this version. If the interviewer requires every comment at every client, remove sampling from the proposal and accept the larger bandwidth and recovery requirements.

Give acceptance and publication separate records

A submission request contains broadcast ID, authenticated author, a request key, and bounded text. The server checks room access, broadcast state, rate limits, and content size. Repeating the same key and payload returns the same comment ID; using that key for different text is a conflict.

Persist the comment and its moderation work obligation together. A dispatcher can recover an unacknowledged job from an outbox or equivalent durable mechanism. The author’s acknowledgment comes from the accepted record, not from whether a fan-out relay happened to receive a packet.

The moderation service works against a comment version. An approval applies only to the expected pending version. A moderator removal advances the version again. After removal creates C7 version two, an approval expecting its original pending version zero is rejected. Record actor, decision, policy revision, and timestamps in restricted audit storage without placing sensitive reviewer details into public events.

Publishing the state transition and its delivery obligation also needs a recoverable boundary. Otherwise a database commit followed by a failed publish can leave a visible comment absent from all live viewers. A relay may send the same transition more than once; downstream processing must tolerate that.

Separate three kinds of order

A comment ID identifies the entity. A comment version decides which state supersedes another state of that entity. A per-broadcast event sequence orders the durable public transitions. None of those is a viewer’s local clock.

For the baseline design, a logical broadcast writer assigns event sequence numbers. Its failover must preserve a fenced writer generation and recover the committed position. This gives a clear contract at a coordination cost. Sharding unrelated rooms helps overall throughput but does not remove the hottest room’s ordering bottleneck.

If one room exceeds the writer’s measured capacity, compare partitioned ingress with a merge stage against a weaker room-ordering guarantee. Explain the changed guarantee before adding shards. An approximately time-ordered display may be sufficient; moderation correctness still needs per-comment version checks.

Prevent a removed comment from returning

Here is the original failure trace. C7 becomes visible at comment version one, event sequence 105. A moderator removes it at version two, event sequence 106. Network paths deliver the removal first. The client stores C7’s version-two tombstone even though it has never displayed C7.

When delayed event 105 arrives, its version one cannot replace version two. A repeated publication packet also cannot restore the text. If deletion only removes an existing DOM element, the first removal does nothing; delayed event 105 can then display C7 again.

Official API fact: Twitch’s EventSub reference identifies the removed message in its chat-message-delete event. That illustrates why stable target identity matters. The version numbers and ordering protocol above are this article’s proposal, not a claim that Twitch implements this exact model.

Treat a removal as authoritative state, not an optional visual animation. If restoration is a product feature, define a separately authorized transition to a higher version; never infer restoration from a delayed publication. Tombstone retention must cover every replay or cache path that can still emit old state, or those paths must require a fresh snapshot.

Scale fan-out without multiplying database reads

A proposed delivery hierarchy sends the broadcast stream to regional relays, then connection servers, then subscribed viewers. Read committed transitions once per downstream group rather than querying the database for every viewer and every comment. Connection servers maintain bounded subscription maps and outbound queues.

For illustrative arithmetic, assume 100 public comments per second, 100,000 viewers, and a 300-byte delivered event. Sending every comment to every viewer produces 10 million deliveries per second and about 3 GB per second of application payload, or 24 gigabits per second before protocol and encryption overhead.

With 100 downstream relays, each receiving one copy of the full stream, the origin sends roughly 30 KB per second to each relay. That reduces duplicated work near the origin; it does not remove the aggregate viewer egress. Connection count, regional distribution, reconnection bursts, and actual serialized event size still affect capacity.

These are stated interview assumptions, not a production benchmark or a claim about a named video platform. Measure fan-out queue age and egress at each tier. Adding more connection servers helps only if the upstream relay and ordered writer can keep them supplied.

Sample ordinary comments while preserving control events

During a burst, a proposed viewer mode might reduce 100 eligible comments per second to ten displayed comments per second. Label that mode honestly. A submitted comment can remain valid in storage without appearing in every sampled view.

Sampling must not discard removals for comments a client might hold. Permission changes, broadcast shutdown, and reset instructions also need reliable application handling. Give these control transitions priority and bounded delivery capacity. If a client cannot keep up with them, invalidate its stream and require an authoritative refresh instead of silently continuing with stale content.

Define a delivery cursor for the selected stream. It cannot be treated as a contiguous cursor over every raw broadcast event when sampling intentionally omits events. A server-issued resume token can bind the broadcast, selection policy, authorization generation, and replay boundary. Change the policy deliberately when resuming, or issue a reset.

At the interface, batch updates and bound the rendered list. Keep a viewer’s paused scroll position stable and expose a new-comments indicator. Rendering fewer rows improves responsiveness, but it is separate from whether the server delivered a complete or sampled stream.

Recover from disconnects without skipping a gap

Official API fact: YouTube’s streamList documentation describes recent history followed by pushed messages, with a continuation token for resuming after disconnection. Its documented response order and token behavior are API facts; they do not establish this proposal’s internal storage or retention choices.

For a complete, unsampled room stream, keep the largest contiguous applied event position. In the C7 example, receiving event 106 first leaves that recovery position at 104. The client can apply the removal immediately for safety while retaining the gap. Once event 105 arrives, the contiguous position can advance through 106.

If the client resumes after its maximum observed sequence, 106, the server will not replay the missing 105. C7 happens to remain removed, but a missing event for another comment could disappear permanently. Bound the out-of-order buffer and request reset when a gap cannot be repaired within the replay window.

A reset returns an authorized state snapshot with boundary S and resumes after S. The snapshot must include deletion protection appropriate to that boundary, not just visible text. An old packet at or below S cannot overwrite it. Coordinate snapshot construction and stream subscription so events committed during the handoff are replayed rather than lost.

Keep the live bus separate from recovery storage

Official delivery fact: Redis documents Pub/Sub as at-most-once: a disconnected or failing subscriber cannot rely on receiving a missed message later. Therefore a volatile Pub/Sub channel alone cannot implement this design’s durable replay guarantee.

It can still be a low-latency notification path when an authoritative log or state store supplies recovery. A relay detects missing positions and catches up from that source. If the relay restarts, it recovers its position and current authorization rather than assuming its former channel subscription preserved history.

Authenticate subscriptions as well as writes. Recheck permission on reconnect and propagate revocations to active connection servers. A room name supplied by a client is not proof of access. Keep pending comments and internal moderation details out of public replay and caches.

For a multi-region extension, state which region owns each broadcast’s write order and how failover fences the previous owner. If the product permits temporary regional divergence, explain how removals propagate and how reconnect reconciles state. Saying “eventual consistency” does not specify those user-visible outcomes.

Test ordering and recovery with explicit limits

The saved Python 3.12.14 run passed twenty-seven checks of the local state and delivery-reordering model. Its four-event scenario covers two comments, each published and removed. It evaluates all twenty-four event permutations with a duplicate removal inserted at five positions, producing 120 reordered and duplicate delivery cases checked against an independent expected final state: both comments remain hidden.

Additional checks cover idempotent submission, conflicting keys, pending versus public state, stale moderation decisions, event identity conflicts, wrong-room rejection, a contiguous cursor, an expired replay window, snapshot-plus-suffix recovery, bounded gap reset, and ended-broadcast submission rejection.

This is an in-memory sequential model of a complete unsampled stream. It does not run a broker, database transaction, browser, network, real authorization service, sampling algorithm, or moderation classifier. It does not measure throughput, deletion propagation time, security, or harmful-content detection quality.

The next integration checks should crash a publisher after a committed transition, disconnect a relay before removal, reconnect at an expired cursor, and saturate ordinary delivery while control events continue. Measure acceptance latency, publication delay, oldest outbound item, replay gap age, reset rate, and removal propagation separately. Each metric identifies a different failure boundary.

Practice five related design questions

The following public practice prompts vary the contract. Their company labels come from candidate-reported material on PracHub; the proposed answers in this guide do not predict an employer’s architecture or interview loop.

Open Design real-time live comments and deliver removal 106 before publication 105. Explain the hidden state, the recovery cursor, and what changes when the viewer receives a sampled stream.

Sources and Further Reading

• YouTube Live Streaming API: liveChatMessages.streamList — documented streaming, history, response ordering, and resume-token behavior.
• Twitch EventSub reference: Channel Chat Message Delete Event — target message identity in a deletion event.
• Redis: Pub/Sub delivery semantics — at-most-once delivery and the distinction from persisted streams.