Loading...
Shortening a URL that is unique
highly available, bandwidth, size, scale
each character is around 2Byte, the URL should be something like www.example.com/SOMETHING. the size of "SOMETHING" can be around 7 chars[0-9Aa-Zz], including numbers so in general 10*52*7=3640 options.
user request to server:l
{
http: POST
body: {
userId: int
url: string
}
}
server to zookeeper:
{
http: POST
body: {
userID:int
url:string
keyId: int
}
}
zookeeper to DB:
{
http:POST
body:{
userID:int
url: string
shortURL:string
}
}
here the read and write can be fast and in a huge size, relationship doesn't seem to be an important feature here between links so there is no point of using relational DB. Instead we can benefit from No-SQL for fast read and write. also no sql is unstructure so we don;t need to be necessarily worried about it
user send a request with a URL that wants to be shortened. the request should go through a load balancer in case there are many request coming. then from LB the request goes to a server such as zookeeper to make sure that the request is going to be unique and no collision happens. then the result would be saved in a NO-SQl database and at the end we send the response to the user. We can have a cache here as well to cache some of the famous URLs or etc
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...
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...
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?