Designing Scalable Comment Systems: Data Models, Threaded Replies, and High‑Concurrency Optimizations

Comment sections are essential for articles and videos because they boost user engagement, facilitate discussion, and increase content attractiveness. This guide explores the design of a comment module.

1. Basic Design

Comments can be nested: a first‑level comment may have second‑level replies, and those can have third‑level replies. Only the number of lower‑level replies is shown initially, reducing visual clutter.

To support this, a generic topic table stores the source type (article, video, etc.) and a count field that records the total number of comments for quick display without scanning all rows.

The comment storage uses two tables: an index table that holds metadata (root, parentId, count) and a content table that stores the actual text, reducing memory usage for each query.

Each comment records its root (0 for first‑level) and parentId . The count field stores how many direct child comments exist, enabling the front‑end to display only the number of hidden replies.

2. Saving Comments

When a user submits a comment, the request passes through Nginx and the API gateway to the comment service, which immediately publishes a message to a message queue. Worker threads consume the message and write the comment to the database asynchronously. After the write succeeds, the service pushes the new comment to the client and synchronizes the data to Elasticsearch via Canal for operational analytics.

3. High‑Concurrency Optimizations

To handle massive traffic, common techniques include:

Caching hot comments in Redis with periodic refresh and expiration to serve frequent reads without hitting the database.

Read/write separation: route read‑heavy operations to replica databases while writes go to the primary, reducing load on the master.

Asynchronous writes via MQ, which decouples the request path from the database transaction and improves response time.