System requirements

Functional:

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

• Users can publish new comments.
• Users can reply to other users' comments
• The system guarantees to show the same comment order for every user
• The user gets a notification if another user replies to his comments
• Let's restrict the one comment thread, which may have 1000 items and only 4 nested depths. (It would ignore the comments if its depth exceeds 4).
• Users can't delete or change the comments; they can only append new ones.

Non-Functional:

List non-functional requirements for the system...

• This service should be highly available.
• This service should be highly scalable.
• When users publish comments, the new comments appear with a delay of 10 milliseconds.
• The service should be highly reliable.
• Only registered users can append comments, others may only read.
• The users can use the mobile or web applications.
• The comments will be shown in chronological order
• The comment can have only text.

Capacity estimation

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

1 million daily active users.

Every user leaves 5 comments per 5 minutes.

Every user reads 10 comments per 5 minutes.

We are going to use RDMS to store user and comments information:

The table Users:

id string (100 bytes)

name string (100 bytes)

email string (100 bytes)

createdAt timestamp (8 bytes)

active boolean (1 bytes)

The table Comments:

id string(100 bytes)

userId string (100 bytes)

parentId string (100 bytes)

level byte (1 byte)

createdAt timestamp (8 bytes)

content bytes (400 bytes)

type byte (1 byte)

Users write 17000 new comments per second or 34 MBytes per second.

Users read 34000 comments per second or 34 MBytes per second.

The system persists 1 Petabyte of comments for 1 year.

The system persists 5 Petabytes of comments for 5 years.

API design

Define what APIs are expected from the system...

We use REST API:

add_new_comment(user_id, comment_payload, timestamp): add new comment by the registered user. It returns id of the new comment and HTTP code 201

add_reply(user_id, comment_id, comment_payload, timestamp): Add a new reply to a comment by a registered user. It checks if the depth's comment is less than or equal to 4 and the comment length is less than 400 bytes; if it fails, it returns HTTP code 400, otherwise is HTTP code 201

get_comments(api_key, comment_parent_id, startDate,endDate, offset, page_size) return JSON with found comments. If comment_parent_id is -1, it returns the comment of level 0. The api_key is to throttle the user request frequency. StartDate and endDate to filter the comments by createdAt. offset and page_size regulate the number of reply comments and allow scrolling up and down by comment list.

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

We are going to use RDMS to store user and comments information:

The table Users:

id string (100 bytes)

name string (100 bytes)

email string (100 bytes)

createdAt timestamp (8 bytes)

active boolean (1 bytes)

The table Comments:

id string(100 bytes)

userId string (100 bytes)

parentId string (100 bytes)

level byte (1 byte)

createdAt timestamp (8 bytes)

content bytes (400 bytes)

type byte (1 byte)

The table Comments has the foreign key of the user of the table Users. In order to optimize the search an user or a comment, we will create the indexes:

(id, createdAt,active) for the table Users;

(id, userId) and (id, parentId,level,createdAt) for the table Comments.

We will use Postgres as the RDMS. It supports replication ,indexing, and transactions.

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

See the diagram from the high-level architecture.

API Gateway provides DDoS protection and TLS termination and forwards requests to the right service nodes.

We have three microservices. User service manages the adding, updating, or deleting of the users. Message service caters to adding new messages and replies. The notification service updates the mobile or web application if other users reply or add new messages.

The message service prefetches user messages and builds the comments in the cache. Also, the messages service sends messages updates to Kafka for the notification service.

The User service caches the frequently used users.

The Notification service caches the user application connection information to send updates to mobile or web applications. The microservices use HTTP REST for communications. The web or mobile application may use the long polling to get the message update

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

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

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

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

Future improvements

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