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: The web browser or mobile app used by users to read and post comments.

Load Balancer: A load balancer to distribute the traffic across various servers in the service.

Comments Service: The main service that manages read / load comments

Comments Database: The database that stores comments-related tables.

AAA Service: A service that manages authenticating users and the users' permissions.

Users Database: A database that stores user-related tables.

Cache: A cache that stores recently loaded comments to reduce read time.

Data Retention Job: A job should be run periodically to remove comments older than 3 years.

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:

1. The client sends a request to the comments service and reaches a load balancer first.
2. For write requests, the comments service forwards the user information to the aaa service, and checks if the user is allowed to perform the write requests.
3. The aaa service should query the User Database for necessary information
4. The aaa service responses to the comments service.
5. The comments service sends read / write records request to the cache.
6. If there is a cache miss or if the request is a write request, the cache queries the comments database for read / write.
7. The cache returns the read / write records response to the comments service.
8. The comments service returns a response to the client.

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...

Cache: The cache is added to reduce the system turnaround time for reads.

Load Balancer: We chose a load balancer because we have a large-scale system and would like to distribute the traffic across various comments service servers.

Databases: Although the data could theoretically be stored in a single machine, we'd like to have a few redundancies to maintain the system's availability. Therefore, we should have duplication of the databases, ideally in the master-slave pattern. Data should be written to the master and read from the slave.

Trade offs/Tech choices

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

The cache in this design is chosen to be read-through and write-through for following reasons.

1. Read-through is chosen to reduce the complexity of the reading process.
2. Users would likely want to read the latest updated comments. Therefore, a write-through is chosen.

Failure scenarios/bottlenecks

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

Examples of failure scenarios are as follows:

• If a user who does not have write permission attempts to write a comment, the request will be sent to the AAA service first to verify its permissions. The AAA Service will query the Users Database to determine whether the request should be rejected.
• When a read/write to the Comments Cache fails, the Comments Service can retry a few times. The Comments Service should return a 500 error to the client if the failure is persistent.
• If the cache fails to sync its data to the Comments Database, it should fail the request (will retry by Comments Service) to keep the data consistent.

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.