Loading...
Requirements
Functional Requirements:
Text: the users can comment a text of 500 words.
Answers: The user can reply to a comment another user left there.
Comments: The comments come before the first comment.
Edits: the user can edit or delete the comments
real-time notifications: the user must see the real time notifcations
Non-Functional Requirements:
- Scalability — one line: "Must handle millions of comments/threads; read-heavy workload; horizontal scaling via Lambda."
- Low latency — one line: "Sub-second thread loads; posting feels instant."
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
API Design
Write API — REST
POST /v1/posts/{postId}/comments
Create a new root comment.
POST /v1/comments/{commentId}/replies
Create a reply to an existing comment.
PATCH /v1/comments/{commentId}
Update an existing comment.
DELETE /v1/comments/{commentId}
Delete an existing comment.
Read API — GraphQL
Query:
post(id: ID!) {
comments(first: Int, after: String) {
id
text
createdAt
author {
id
name
}
replies(first: Int, after: String) {
id
text
createdAt
author {
id
name
}
}
}
}
High-Level Design
| ServiceResponsibility | |
| API Gateway | Provides the public API entry point and routes read and write requests to the appropriate backend service. |
| Read Service | Handles GraphQL queries and retrieves comment data from the cache, falling back to the database when necessary. |
| Write Service | Handles REST commands such as creating, updating, and deleting comments and persists changes to the database. |
| Cache Layer | Stores frequently requested comment data to reduce database reads and improve response latency. |
| NoSQL Database | Acts as the source of truth for comments, replies, relationships, and persistent comment state. |
| Event Bus | Publishes comment-domain events such as CommentCreated or ReplyCreated to independent asynchronous consumers. |
| Cache Queue | Buffers cache-update events so temporary processing spikes do not overload the cache worker. |
| Cache Worker | Consumes cache events and invalidates or refreshes stale cached comment data. |
| Notification Queue | Buffers notification events independently so slow notification processing does not affect cache synchronization. |
| Notification Worker | Consumes comment/reply events and determines which notification operations must be executed. |
| Notification Service | Delivers notifications to affected users through the configured notification channels. |
| Dead Letter Queue | Stores messages that repeatedly fail processing so they do not block normal queue consumption. |
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
| Scenario checkWhat to say | |
| How will you ensure real-time notifications for replies? | Use an event-driven notification flow where a ReplyCreated event is published after persistence, consumed by a notification worker, and pushed to connected clients through WebSocket/SSE or a push-notification service. |
| How will you route notifications across instances? | Keep notification workers stateless and use a shared broker/pub-sub layer to route events so any worker instance can consume and deliver the notification, with connection/session mappings stored in a shared distributed store if persistent connections are used. |
| ConcernWhat to add | |
| Duplicate comments during retries | Use an idempotency key per write request so repeated retries return the original result instead of creating another comment. |
| Cold cache / thundering herd | Use request coalescing / distributed locking, cache warming, and short randomized TTLs so many simultaneous misses do not all hit the database. |
| Concurrent tree updates | Use conditional writes / optimistic concurrency control so replies are only attached if the expected parent/version still exists. |
| Edit/delete authorization | Authenticate the caller and enforce ownership/role checks in the write service before allowing comment mutation. |