Designing a Scalable Comment System: Architecture, High Concurrency, and Moderation

Motivation

A high‑profile live‑stream incident highlighted that the comment system failed to differentiate user roles and filter problematic remarks, motivating a robust comment architecture.

Functional Requirements

Comment posting and reply : Users can publish comments and reply to others.

Like/Dislike : Users can express preference on comments.

Comment retrieval : Supports sorting by time or popularity with pagination.

Admin controls : Hosts can toggle a preference switch, mute users, delete or report comments.

Non‑Functional Requirements

The system must handle massive data and high QPS. Example scale: a platform with 1 billion users, ~200 million daily active users, ~20 million comments per day, peak traffic of 100 k QPS and 10 k comment writes per second. Traffic and comment volume are uneven across live rooms and time.

System Design

Long‑Connection Management

Both viewers and hosts maintain long‑running TCP connections to receive real‑time notifications. A User Long‑Connection Management Service stores TCP server addresses in Zookeeper. On first login or reconnection, a client requests a new address and establishes the TCP connection to the selected server.

User Service

The user table stores:

user_id : unique identifier

name : username

portrait : compressed avatar

addr : geographic location

role : viewer or host

Live Service

The live table records:

live_id : unique live session identifier

live_room_id : unique live‑room identifier

user_id : host’s user ID

title : live topic

Attention Service

The attention table links users to live rooms for follow notifications:

user_id : follower’s ID

live_room_id : followed live‑room ID

Comment Service

The comment table includes:

comment_id : primary key

user_id : commenter’s ID

content : comment text

timestamp : creation time

parent_comment_id : ID of the comment being replied to (null for top‑level)

live_id : associated live session

level : nesting depth

Additional optional fields such as like count, dislike count, and report count can be added.

Push Service

A message queue (e.g., Kafka) decouples event generation from delivery. When a live room starts, a “live start” topic is produced; the push service retrieves TCP server info from Redis and notifies users. Comment replies are similarly queued. A delayed queue stores notifications for offline users, which are delivered when they reconnect.

Performance Optimizations

Distributed Architecture : Traffic is spread across multiple servers to avoid single‑point failures.

Message Queue : Asynchronous processing reduces load on the main service.

Cache Layer : Redis caches hot comments and user location using an LRU strategy, lowering database pressure.

Security and Protection

Text Filtering

A Bloom filter quickly detects known sensitive words. The filter hashes each word multiple times into a bit array; a missing bit guarantees absence, while all bits set indicates a probable match (false positives possible).

Initialize a bit array to 0 and define a set of sensitive words (e.g., {"菜狗", "尼玛", "撒币"]).

Hash each word with three hash functions, setting the corresponding bits to 1.

To query a word, hash it with the same functions; if any bit is 0, the word is definitely not in the set; if all three bits are 1, the word is considered present.

False positives (e.g., the word "天气") may occur, but the structure is space‑efficient and fast for large‑scale filtering.

User Restrictions

User authentication : Only logged‑in users may comment.

Rate limiting : A user can post at most 10 comments per minute per live stream.

Advanced Moderation

Sentiment Analysis

A daily job extracts new comments, stores them in object storage, and feeds them to an NLP model that predicts an emotion flag (TRUE for positive sentiment). Hosts can enable a “preference switch” to hide comments with emotion = FALSE, showing only positive feedback.

Machine‑Learning Recommendation

Behavioral models can identify “true fans” versus low‑quality commenters, allowing hosts to selectively enable commenting for specific user segments.

Conclusion

By combining a hierarchical comment model, distributed processing, caching, Bloom‑filter security, and optional AI‑driven moderation, a scalable, reliable, and user‑friendly comment infrastructure can be built for high‑traffic live‑stream platforms.