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.

Capacity estimation

Estimate the scale of the system you are going to design...

Let's assume we have:

• Number of Active Users: 100,000
• Comment Activity Rate: 5 comments per minute
• Concurrent Users: 10,000 during peak hours
• Average read requests per user:
• 2 read requests per minute to fetch comments for threads
• 1 read request per minute to refresh new replies or comments in active discussions
• User Interactions: 2 likes and 1 reply per comment on average

Based on these estimations, on average an active user issue 3 read requests per minute.

Total read requests rate = 10000 (peak users) * 3 (requests per minute per user) = 30000 read requests per minute.

Average write requests per minute - 5 * (1 (comment) + 2 (likes) + 1(reply) = 20

Assume each comment and its replies cost around 1KB. We need to store

5 (comments per minute) * 60 * 24 * 365 * 3 = 8GB data.

This data could be stored in a single database machine.

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

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

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.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

The request flow should be as follows:

There are two main request flows:

When a user logs in and starts to read a topic.

1. The client calls the Gateway Server to subscribe to the topic.
2. The Gateway Server stores the subscription information in its in-memory subscription store.
3. If this is the first client in this Gateway Server to subscribe to the topic, the Gateway Server will subscribe to it by writing this subscription information to the endpoint store.
4. The Gateway Server establishes an SSE (Sever-sent Event) connection with the receiver client.
5. The Gateway Server fetches all comments for this topic from the comments store and returns them to the receiver client.

When a user publishes a comment on a topic:

1. The publisher client requests that the Dispatcher Server publish the comment.
2. The Dispatcher Server stores this comment in the comments store.
3. The Dispatcher Server queries the Endpoint Store to discover all Gateway Servers that subscribe to the topic.
4. The Dispatcher Server dispatches the comments to the Gateway Servers.
5. The Gateway Server then queries its in-memory subscription store to find all receiver clients who subscribe to the topic.
6. The Gateway Server sends the comment to the subscribed receiver using SSE.

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.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

SSE is chosen over a pull-based model for communication between Gateway Server and the receiver as

1. To achieve realtime experience in pulling model, the pulling frequency has to be high.
2. A lot of pulling requests would result in no updates, network bandwidth would be wasted.
3. Polling solution is also not scalable as we have more and more receivers.

SSE is chosen over web socket for the following reasons:

1. In this system, there will be much more read than writes, which makes SSE more suitable than web socket.
2. SSE is simpler and are generally better supported by browsers.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Examples of failure scenarios are as follows:

All components, except for publisher and receiver, should have duplication to distribute load and increase reliability.

• The Gateway Server would be the only service that contains state, if a gateway server crashes during a session, the receiver should be able to connect to a different gateway server, and fetches all comments again.
• If a storage fails, the dispatcher could query different copies of it.
• If a dispatcher fails, the publisher should be able to connect to a different dispatcher to re-attempt the write process.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

In the future, more duplications and partitions should be introduced as the user scale up.