Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
the system should provide a way to view messages in a nested comments format, where comments can be connected and viewed in the correct order
List non-functional requirements for the system...
highly available
high consistency, everyone needs to see the same order
Estimate the scale of the system you are going to design...
10 million users, 1 million active
10 comments per day per active user
roughly 1 Gb/day assuming text only
Define what APIs are expected from the system...
create_post(user_id, text,timestamp)
POST api/v1/new_post
comment(user_id,text,previous_comment,timestamp)
POST api/v1/{previous_comment}/text
user_id can be used for rate limiting
previous_comment will be a link
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...
A linked list makes lots of sense here, where in each comment is its own class instance with the attributes:
Redis would be a great LRU cache to store the most frequent comments. That way we can have quick access to
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...
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...
create comment => load balancer => application server
create unique id for the comment and set timestamp as well
all of this stored in MongoDB which allows for nested documents
returns a success message once the comment is created
add comment => load balancer => application server
if its past 10, then go into a nested structure (see Failures/bottlenecks)
see comment => load balancer => application server => return comment
It returns the specific comment in the nest (lets say comments 11-20 of a whole set) as well as the PK for the previous batch and next batch. That way the front end can have a button saying "load more" both above and below and there can be a simple react script such as onClick -> load that batch. That way the user can have a seamless time. If we have high bandwidth, we can auto load the previous and next, and store the next set of keys on either end
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...
a microservice will be sorting comments by timestamp. It will display the comments to the user in order of most recent comments.
Explain any trade offs you have made and why you made certain tech choices...
Since each message is a doubly linked list with a hash for the next message as one of the attributes, I was thinking that a KV store makes sense. however, each list node has multiple attributes so MongoDB makes more sense
Deleting comments could prove problematic, as removing a comment (especially a top level comment) could cause problems. I think it makes most sense to change the value to "This comment has been deleted" and go from there. That way we dont introduce complexity into the system.
Try to discuss as many failure scenarios/bottlenecks as possible.
If a user deletes a comment with active comments, we can simply change the text to "the user has deleted this comment" and then change the user name to "deleted. Much like reddit.
The nested structure of MongoDB is great for this, but it introduces some complications. What if we request the 245th comment via a link? Do we grab the first comment and iterate down? That seems like a good idea to save space, but its not the most robust. What if we split up comments once the nested lists got past 10? Then we could render the important ones first to the UI, then slowly feed the rest to the front end. Aka if the user scrolls up, it loads the next comments. We could keep the PK of the previous and next bunch within each json object, and use loading indicators to make sure that the user has a seamless experience.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?