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
| ServiceWhy | |
| DNS | Resolves the application domain to the correct public endpoint. |
| CDN | Caches content closer to users to reduce latency and backend traffic. |
| DDoS Protection | Protects public endpoints from large-scale denial-of-service attacks. |
| WAF | Filters malicious HTTP requests before they reach the API. |
| API Gateway | Provides a controlled entry point for routing, securing, and throttling API requests. |
| Read Serverless Function | Handles GraphQL read requests and retrieves comments primarily through the cache. |
| Write Serverless Function | Handles REST commands and persists comment changes to the source of truth. |
| Cache Layer | Serves frequently requested comments quickly and reduces database reads. |
| NoSQL Database | Acts as the source of truth for comments and their hierarchical relationships. |
| Pub/Sub | Distributes database-change events asynchronously without coupling producers to consumers. |
| Background Worker | Consumes change events and invalidates or refreshes stale cache entries. |
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.