Loading...
Users should be able to create a TinyURL with their given long URL.
System should be able to redirect user with their given shorten URL.
System should be highly available where system is not down.
Prioritizing availability over consistency is important because having system down is more critical than system is not being consistent
System should be scalable where it can take growing number of users.
System should have real-time expereince/low latency.
Assuming we have 100M URLs get created per day with 1:100 write:read ratio.
100M/86400 sec = write qps
100M*100/86400sec = read qps
assuming each url is about 10bytes stored for 5 years,
10bytes*100M*365 would be storage per year
Define what APIs are expected from the system...
there are Three APIs.
Get - With given shorten url, return the original URL
Parameter would be shorten url
Post- with given long URL, return shoren URL that users can use
parameter would be long url
Delete - with given shorten url, delete the url
parameter would be shortnen url
System is not too complicated that we will be focusing on Users, URLs models.
Users would have pretty much straight forward like username, password, email, urls they own.
URL would have shorten url mapped to long url, url ID, ownerID, creationdate, and expiration date.
I would choose nonrelational db over relational because we need to also think of scalable. having nosql would be easier for us to scale
Clients are making a request either creating new shorten URL or hitting shorten url to go to their original link.
Once clients are making the request, load balancer will help to distribute large amount of traffic as well as to correct service based on which type of request they are making.
if it is the case to get redirected, system twill check the cache system if url exists in cache. But if it doesn't exist, then it will get the data from database and return back to users.
if it is the case to shorten url, system will take reqeust to url creation service. this service will generate a new shorten url and insrt the proper set of data into database. and service will return the new shorten url to user with proper response code.
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?