Requirements

Functional Requirements:

• Allow users to post top-level comments and replies in a nested hierarchy.
• Enable users to edit or update their own comments and delete them; deletion may be restricted if the comment has replies.
• Provide real-time updates or notifications when someone replies to their comment or posts in a discussion they follow.
• Allow users to upvote or downvote comments to indicate quality or popularity; vote counts influence sorting.
• Enable sorting comments chronologically or by popularity.
• Enforce a maximum depth for nested replies.

Non-Functional Requirements:

• System requires:
  • low lag and speed when searching for results
  • quick time for interaction with third party notification service
  • very good performance when posting comments and responding to other comments
  • have comments not dissapear and load quickly when opening the page
  • upvote and downvote process needs to happen instantaneously
  • software should always be up and running and we can focus on availiability instead of consistency

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

GET should retrieve all comments in the database

POST for responding and posting comments on the page

GET for getting the numbers for down and upvotes

POST for sending down or upvotes

GET for message notificaitons

GET results from search

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

On a high level, we need to have a client with a user interface, which connects to a rate limting server which will check if the comment or upvote is valid and if so move on to the api gateway. From here we will go to a load balancer which will distribute our request to one of the servers we have working. A websocket will be in constant contact with the load balancer to ensure constant communication with the comments posted. We also have a queue for down and upvoting so we ensure availibility in our software so the system is never down and finally a database to store all the comments and data on the up and downvotes. We can also store all the comments in a s3 bucket to not slowdown the main database

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

The main component design can be found from the search server where we will use a cache to find frequently searched for results and store them in the cache. This way the system does not always need to touch the s3 bucket or the database when searching for results. We also use a load balancer to distribute the tasks for the system and use microservices to organize the task by servers. We also use a kafka queue when doing down and upvoting so this way the client is not seeing a loading screen when clicking to upvote or downvote. This will ensure the system is always avalibile and running and the queue will process these requests one by one and then count them with a count upvotes and downvotes worker server before touching the database