Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
List non-functional requirements for the system...
Define what APIs are expected from the system...
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.
Client: Let's call normal read path handler client - client
Read Server: Handles read path, will read comments from comments store and returns to client, also update endpoint store and gateway server as needed
Here's the way to handle Create, Update and Delete (Write Path)
Because these operations mutate state and require live updates to other users, they follow the entire flowchart.
POST, PATCH, or DELETE request as the Publisher.topic_idexists, calculates the new nested path, and inserts the record into the Comments Store.is_edited, and updates the Comments Store.thread_id: 123.COMMENT_ADDED or COMMENT_DELETED) to the appropriate Gateway Server.This architecture is heavily optimized for writes and real-time pushes. For standard Retrieve operations (e.g., a user loads the page for the first time), the flow is slightly different:
GET request to a Read API (which could sit alongside or within the Publisher block) that queries the Comments Store (or a Redis cache sitting in front of it) directly to fetch the paginated, nested comment tree.To handle pagination, we need to use cursor-based pagination. Specifically, the initial comments will return the first page and a cursor, and subsequently when user scroll or move to next page, cursor is used to fetch subsequent pages.
To handle lazy-loading of nested comments, the client can send a request to the GET /comments/{topic_id}/{comment_id}/replies API, and the server reads from the comments store and returns the list. Besides, the server also updates the Gateway Server and the Endpoint Store to subscribe to the newly loaded reply path.
Real-time-notification: Once a client read a specific thread, or a specific reply with replies, they subscribe to this topic via websocket or server-side events. Whenever a new reply is available, the dispatcher will read subscriptions from endpoint store, figure out what gateway server needs it, and then the gateway server will forward the update through server-side events to the interested receivers.
API-gateway: This gateway handles authentication of users. It verifies that the user is logged in and also have enough permission to read / post in certain threads. Once that's done, it forwards these information to dispather or read server to further handles the requests.
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.
Comments Store: Comments should be stored in a form of adjacency list: every comment has a parent_id, topic_id and replied_to. In this way, when fetching comments, we can use the WITH RECURSIVE command in modern database.
The system is supporting only two levels of nesting comments, and pagination should be supported when fetching comments store. Nested comments should be lazy-loading, meaning that only when users want to look at the replies of one comment, those comments will be loaded from the database.
Once a comment is added to the system, everyone who subscribed to the topic should get the notification using SSE connection. The SSE subscription should be stored in Gateway Server's in memory subscription store. And the Gateway Server, if not already subscribed to the topic, should in turn add its own subscription to endpoint stores. When a notification should be fend out, the dispatcher should query the endpoint store to find out all gateway server that's interested in the topic, and then the Gateway server who received the notification should use its own in memory subscription store to send notification to receiver. As endpoint store are shared accross all topics and servers, all servers have access to the subscription stage.
To handle upvotes and downvotes, a client calls the API and the dispatcher does the following before updating comments table:
It should insert one line with unique user id + comment id in the corresponding upvote / downvote table. If there is already such an entry, this attempt is duplicate and should be rejected.
Once this is verified and done, the upvote / downvote count inside comments store should be updated as well. This should be handled as atomic updates using SQL, so that even if many users clicked the button together, the update should be queued.
All comments should have an idempotency key, so as to prevent duplication introduced by client retries.
A cache is implemented so that read service can first read from cache, then comments store. In order to avoid thundering herd issue, if there is a cache miss, a thread needs to acquire a lock to read from database. The thread that acquired the lock should read from the comments store and updates the cache. After that, it releases the lock. The rest of the threads should check the cache again before another attempt to acquire the lock.
To handle concurrent operations and maintain tree integrity, we can employ a combination of database-level transactions and optimistic locking. For concurrent replies, wrapping the insertion in a transaction with an ISOLATION LEVEL like READ COMMITTED ensures that a child comment cannot be orphaned by referencing a parent_id that is simultaneously being deleted. For updates and deletes, we can introduce a version column on each comment row; before any modification or soft-delete executes, the application verifies that the version matches the initial read (WHERE id = :id AND version = :current_version), preventing race conditions where two users edit the same node simultaneously. Alternatively, if a hard delete is required, we can use a recursive transaction or atomic cascading updates to either safely re-parent the orphaned child nodes to the deleted comment's parent, or marks the node as [deleted] while preserving its structural position in the tree.
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
Comments Table
Users Table
Upvotes Table
Downvotes Table