Loading...
Generate concise aliases for URLs
Be able to redirect to original URL
Be able to create aliases and save them
List non-functional requirements for the system...
Let's say we will have 100,000 users. Each user will want to save more than 1 URLs, maybe 5.
5 URLs per user, so we need to save 500,000 URLs daily.
Our peak request load
maybe 10% of total traffic - 500000/24*0.1
If it becomes too popular, we would want to horizontally scale the system. Will need a load balancer and multiple servers to handle client requests.
Database needs to be scalable as well.
The API needs to have 2 available functions.
shortenURL(originalURL, userID) -> returns shortened URL and redirects user
callShortenedURL(shortenedURL, userID) -> redirect to original URL
API needs an algorithm to generate a shortened URL relevant to the original URL's name. The URL needs to be able to redirect the USER to the original URL. Be able to map the shortened URL to the original URL, which requires communication with the database and fetch the original URL from the shortened URL.
Database we can use a NoSQL DB. This way it is easily scalable because we can horizontally shared the DB. Also because we are merely creating a key:value pair with the original and shortened URL, there is no need for tables in SQL.
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...
We have a client communicate with our server. The client will either request shortened URL or call a shortened URL. The API will then either create a shortened URL and save the mapping to the Database, or request a mapping from the DB. Regardless in the end the API will redirect the user to the original URL.
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...
Client requests URL or requests to be redirected to a URL given a shortened URL.
The server will either generate a new URL and save the mapping to the Database, or search the database for an already existing mapping. In the end, the client will be redirected to the original URL.
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...
We could have two microservices to handle 2 different requests. One service for generating a new URL, and another service for just fetching from the database. Because there will be many more requests for fetching than creating, we will probably need a load balancer for those requests.
Explain any trade offs you have made and why you made certain tech choices...
NoSQL because it is highly scalable and we are only saving key:value pairs.
In this case, we need to value consistency over availability. If a key:pair gets updated, we will need to redirect them to the proper URL instead of one that no longer works.
Try to discuss as many failure scenarios/bottlenecks as possible.