Loading...
1) Return the short URL to the user for a long URL , create a new short URL if it is not existing already.
2) Redirect the end users to actual URLs whenever short URL is entered.
3) Only owner users can make changes/delete the short URLs
1) System should make sure it is returning the short URLs unique.
2) System should be capable of processing high number of requests at a time.
3) there should be error handling for incorrect URLs
4) system should recover in case of failures.
5) Proper backups should be kept for recovery.
Estimate the scale of the system you are going to design...
1) DB capacity to store URLs for 10 years: Number of new URLs creation are 10000 per day. So 3650000 per year and 73000000 for ten years.
Short URL length is 7 Alphanumeric characters. Long URL length is average 200 bytes. total if 207 bytes per URL mapping. Then total capacity required is 207 X 73000000 Bytes.
2) Number of URLs retrieval are 10000000 per day. which is ~100 TPS
Define what APIs are expected from the system...
CreateNewUser: API will create a new user in the system. Will capture customer information, contact information and will assign a userId to it. Email_id or user Id can be used to login.
AuthenticateUser: Authenticate the user as per userId and password entered.
userCreateNewUrl: User can create a new short URL if not existing already.
GetLongUrl: Return the LongUrl for the given short Url.
GetShortUrl: Return the ShortUrl for the given long url.
DeleteUrl: Delete the short URL for any urls created by the user.
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...
NoSql DB will be used to get better performance. It will have a key value pair. Will capture the user details. Also will capture the Short URL and Long Url mapping for all the URLs created by the user. This table will be heavy and will be sharded based on the key.
table UnusedUrls will hold the unused short URLs. Entry will be deleted from the table once short URL is used.
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...
There will be a load balancer between client and application servers.
HTTP requests/methods will be be used to call the microservices.
One batch job will run once in a day to create the shortUrls and save into UnusedUrls table. It will create the records for given permutations of 7 characters to be used for short URLs. It will make sure that we have 300000 unused URLs at a time which are sufficient for next 30 days and will also keep track of the last used combination of 7 characters to continue from there onwards next time.
Servers will cache 100 unused URLs into memory. Whenever a request comes to create a new Url then server will use the short URL from memory. If there is none then it will request from DB which will return 100 URLs at a time and will delete them from table. It will help to reduce the DB IO requests.
Frequent requested short Urls will be cached into memory to improve the performance.
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...
If a server crashes then we will loose the unused Urls in the memory. so there is a trade off between performace and URLs gap. We can save those URLs by deleting them in the end of batch job by comparing with the URLs mapping table rather deleting them real time.
Try to discuss as many failure scenarios/bottlenecks as possible.
In case of any server failure load balancer will not send requests to this server.
If we are using AWS cloud then elastic load balancer can help to bring up another instance if one server goes down or number of requests have increased.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?