Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
1) Allow user to add a special emojis
2) Allow users to add comment in live system.
3) Allow users to reply to specific user.
List non-functional requirements for the system...
1) System should be highly scalable
2) System should be low latency
3) System should be fault tolorent
Estimate the scale of the system you are going to design...
Number of qps 100,000 *10 =1000,000 lets asssume a single comment is of size 100kb then total memory required 1000,000*100kb=100,000 mb=100gb=0.1 tb
Define what APIs are expected from the system...
we will have two api one two add a comment aond other to get the comments at a particular second using the screen width and height.
we will have two api one two add a comment aond other to get the comments at a particular second using the screen width and height.
1) POST - > /v1/comment -> Request Boday -> { message:""
emojis:[
{
emojiId:1
emojiPos:10
}
]
}
2) GET /v1/comment?time=?height=width= This api will take the time, height, width and displays all the commenst which will fit in the screen for that particular time
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...
The live comment service is a read-heavy system. In simple words, the predominant usage pattern is the client viewing live comments.The major entities of the relational database are the comments table, the videos table, and the users table. The relationship between the users and the comments tables is 1-to-many. The relationship between the videos and the comments tables is 1-to-many. The relationship between the users and videos tables is 1-to-many.
| ColumnDescription | |
| id | ID to identify the comment |
| user_id (Foreign key) | publisher of the comment |
| video_id (Foreign key) | ID of the associated video |
| content | content of the comment |
| created_at | timestamp of creation |
| ColumnDescription | |
| id | identifier of the video |
| title | title of the video |
| user_id (Foreign key) | streamer of the live video |
| created_at | timestamp of creation |
| ColumnDescription | |
| id | identifier of the user |
| name | name of the user |
| email of the user | |
| profile_image | URL to fetch the profile image of user |
| last_login | last login timestamp of the user |
| created_at | timestamp of user account creation |
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...
Each user request first lands on the load balancer, which then routes the request to the CDN. Since we store static content on the CDN, it can quickly serve the content if it's available, reducing the need to contact the web server. If the requested static content is not available on the CDN, the request is forwarded to the web server to retrieve the content, which is then cached on the CDN for future requests. After the static content is handled, any dynamic content requests are routed through the load balancer to the appropriate application server.
For messaging, when a user writes a message, it is published to a specific Kafka topic. A consumer group reads messages from this topic to process them. Additionally, a worker retrieves messages from the Kafka topic and stores them in the database. When a user joins a user group, they can access all messages for that stream by reading from the database.
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...
Each user request first lands on the load balancer, which then routes the request to the CDN. Since we store static content on the CDN, it can quickly serve the content if it's available, reducing the need to contact the web server. If the requested static content is not available on the CDN, the request is forwarded to the web server to retrieve the content, which is then cached on the CDN for future requests. After the static content is handled, any dynamic content requests are routed through the load balancer to the appropriate application server.
For messaging, when a user writes a message, it is published to a specific Kafka topic. A consumer group reads messages from this topic to process them. Additionally, a worker retrieves messages from the Kafka topic and stores them in the database. When a user joins a user group, they can access all messages for that stream by reading from the database.
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...
Each user request first lands on the load balancer, which then routes the request to the CDN. Since we store static content on the CDN, it can quickly serve the content if it's available, reducing the need to contact the web server. If the requested static content is not available on the CDN, the request is forwarded to the web server to retrieve the content, which is then cached on the CDN for future requests. After the static content is handled, any dynamic content requests are routed through the load balancer to the appropriate application server.
For messaging, when a user writes a message, it is published to a specific Kafka topic. A consumer group reads messages from this topic to process them. Additionally, a worker retrieves messages from the Kafka topic and stores them in the database. When a user joins a user group, they can access all messages for that stream by reading from the database.
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?