Loading...
1, Allow individual user to create their own account
2, Tag content with unique tag
3, Search content based on tag
5, Delete/Unlink Tag with content
6, Suggest similar tag group
1, Low latency tag operations
2, Support high availability on tagging operations
3, each user can only access their own tag content
Lets assume if we need to create 100 tags each mins, that will be 6000 tags per hour and 144000 tags per day, storing 259200000 tags for 5 years. And lets say Avg. each tag is associate with 100 bytes storage space, 5 years will require 26 gb space to store.
1 Put /api/tag/{Tag_name} and put the content in the header as requirement to put tag on content
2, Get /api/tag to get the content for the tag
3, Delete /api/tag to delete tag
4, Post /api/suggest/tag to give similar content for the tag name
Considering we do not need complicate query operations, and a easier scalable database is prefer, so Mongodb could be a better choice
User
{
id (key)
user_name
user_email
}
Tag_store
{
id(key)
tag_name
}
content_store
{
id(key)
content_title
}
user_tag
{
id(key)
user_id
tag_id
content_id
}
Client -> server -> ELB -> Database
server also connect to a Cache like Redis for Get request
The Client send api call to server, if it is a Get api call, it will first get content from Redis, for other Api call, it will go through a load balancer to split traffic, and then go to database to manage results
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...
Explain any trade offs you have made and why you made certain tech choices...
High amount of users may cause service crush or increase latency
It is possible that the consistency is not good, if user delete one of its tag, but it is not reflected in cache, he will still get the old content
Maybe add some lock to updating/deleting logic