Loading...
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...
complete CRUD over user with /auth/user - to authenticate users
POST /comment - creates a comment - optional parent comment_id because for root comments its not required. users data extracted from JWT token
GET comment/ - get all root comments for post - input is a post_id, we also can have a optional filter for depth and parent comment_id = it will basically fetch all comments on the level for the parent comment_id = this is our on demand retrieval of comments.
POST comment/vote - parameter up/down - this will add votes on a comment.
DELETE comment/delete - delete the comment and all related comments with cascade.
PUT comment/edit - edit text of comment
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.
high trafic spikes are handled by the fact we have load balancer and KUDA based scaling enabled for all of our workers. Workers scale based on message count and main APIs based on the incomming requests.. minimal replication count is 2. so we always have atleast two servers going for high availability of our service.
Nosql dynamodb - key value store with separated tables per depth - if we want to in future add depth 6 we can simply do it by adding a new table. Clients holds the info for what depth and what commment_id we need to return data. We load data on user request on-demand. When he wants to load replies or more comments. geo replication is under the hood handled by dynamoDB along with correct partitioning.
Fast reads are provided by design - a nosql dynamodb takes care of all the partitioning and we have the separate tables so it should be very fast even for milions of replies and comments in each table.
notification service - we can utilize a amazon dynamo db streams that can take care of adding a new notification based on what data has been inserted. But to make this interesting I want to use a specific microservice to handle this. we have notifications for votes on your comments, somebody replied.
main service - orchestrator of the insert to database and populating notification table so notification service/worker can send a notification to user. It has a separet workers to handle tasks:
deletion workers - it takes care of deletion of orphaned workers. it first deletes the main comment so we cant call for its data anymore then a jobs will spawn in queue to delete all depths for all comments. this is only one full tree scan we have.
voting workers - it will take care of updating the vote number on the comments - so basically if there is burst of upvote/downvote this event-driven architecture will take care of it with eventual consistency on scale which is enough for me.
auth service - using a nosql database with authentication of users - it will reflect the user_id in comments tables.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
NOsql desing -
comments has a idempotent key. Separate tables has a GSI indexes with the comment_id of the parent which means it can load just data it needs very easily to avoid a full tree scan.
on demand loading based on depth_level: number and comment_id = uuid of parent comment.
easily extendable just add a depth table 6 if we want a new depth
Cache - all coments are editable - if somebody reads a cache we create a cache record for the most frequently accessed comments. TTL could be 1hour if somebody edit the comment we have eventual consistency we first in the main service read the comment edit it and then go to cache read the record and edit it also there.
Notification service - has its workers subscribed to queue main service is sending the notification data here. It sends commend_id and our notification service get the data of all users it should notify and creates a new messages per notification for a notification_dispatcher worker that then sends the notification to users one by one.