System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. Nested Structure: The system should support 2 levels of nesting where users can reply to comments in a hierarchical structure.
2. Real-Time Updates: Users should be able to view new comments and replies in real-time without the need for manual refreshing.
3. Order Preservation: The system should maintain the order of comments and replies within each thread to ensure the chronological flow of the conversation.
4. Moderation: The system should include features for moderating comments, such as deleting inappropriate comments.
5. User Engagement: It should allow users to interact with comments, such as liking, replying, and sharing.
6. Authentication and Authorization: Users should be able to authenticate themselves and the system should enforce appropriate access controls.
7. Data Retention: The system should retain 3 years worth of comments.

Non-Functional:

List non-functional requirements for the system...

1. Scalability: The system should be able to handle a large number of concurrent users and comments efficiently.
2. Responsive Design: The system should provide a seamless user experience across various devices, such as desktops, tablets, and mobile phones.

API design

Define what APIs are expected from the system...

• POST /comment
• request:
• content(string)
• response:
• status: (success / fail)
• comment object
• id: (comment_id)
• content (string)
• poster_id (id of user posting the coment)
• poster_display_name (string)
• timestamp
• GET /{topic_id}/comments?last_timstamp={last_timestamp}&size={page_size}
• response:
• status: (success / fail)
• topic_id
• topic_title
• created_at
• comments
• id
• content
• poster_id
• poster_display_name
• commented_at (timestamp)
• replied_to (id of the comment that this replies to)
• upvote_count
• downvote_count
• POST /comment/{comment_id}/reply
• request:
• content
• response:
• status
• comment
• id
• content
• poster_id
• poster_display_name
• commented_at
• replied_to
• PUT /comment/{comment_id}/upvote
• response
• status
• PUT /comment/{comment_id}/downvote
• response
• status
• DELETE /admin/{comment_id}
• response
• status

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

The system should include the following items:

Client (Publisher + Receiver): The client plays two different roles in the system: comment publishers and comment receivers.

Servers (Dispatcher + Gateway Server): The servers play two roles in the system: the dispatcher broadcasts the comments to appropriate servers (and subsequently receivers), and the Gateway Server forwards them to the receivers.

Storage (Endpoint Store + comments store + in-memory subscription store): The system has three storage locations—the comment store stores comments, user information, etc. The Endpoint Store contains information on which gateway servers are subscribed to what topics. The In-memory subscription store resides in the Gateway Server and contains information on which receivers want to receive comments on which topics.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Gateway Server: In order to achieve real-time comments refresh, each gateway server maintains SSE connections to all receiving clients. Each server also contains an in-memory subscription store, so that it does not fan out comments to all receivers unnecessarily.

Endpoint Store: This storage is stand-alone so that dispatchers does not need to maintain a state, therefore, the publishing load can be flexibly distributed across all dispatchers.

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Topics Table

• topic_id - string
• title - string
• created_at - timestamp

Comments Table

• comment_id
• topic_id - foreign key, id of the topic this comment belongs to
• poster_id - foreign key of user table.
• replied_to - optional, id of the comment that this comment replies to, if applicable
• commented_at - timestamp
• upvote_count
• downvote_count

Users Table

• user_id
• user_display_name
• role

Upvotes Table

• user_id
• comment_id

Downvotes Table

• user_id
• comment_id