Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
Turn a long url into a short url that still points to the long url
User inputs a url of a certain length
We return a shortened version of that url
List non-functional requirements for the system...
Speed, security and overall ease of use
Estimate the scale of the system you are going to design...
Depends on how many urls we want to save at a time, which depends on how many users we will have that use the url shortener daily
Depending on the usage of the URLs, we can implement an LRU cache to achieve efficiency. In the event we have many, many users, we can prioritize the links and requests that are used most often.
Define what APIs are expected from the system...
API to store url and a shortened version of the url
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...
Database can store URLs as keys, and we will create shortened URL to store as value.
Database can be a large object where { old_URL : short_URL, ... }
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 go from the client to our server, where we shorten the url and save it into our database. Once we store it, making a call to our shortened url should make a request to our server, which will then fetch the url from our database and direct the user to the correct 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...
The client will make a request to the server to shorten a URL. The server will create a shortened version and save both the original URL and the shortened URL to the database.
The user will then be able to use the shortened URL.
When the shortened URL is called by the client, a request to our server will be sent. We will do a query of the database from the server to search for the original URL, and send that back as a response. The user will then be able to go to the original URL using the shortened version of the URL.
If the client makes a request to shorten a URL that already exists in our database, we can check if the URL exists in the database first before we add to the table.
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...
The only scalable component will most likely be the database.
The server should be able to quickly handle requests as it sends requests directly to the database. If necessary, multiple servers can be set up with the same function to reduce workload.
The database will be some kind of table, where the columns will have the original URL and shortened URL saved.
Explain any trade offs you have made and why you made certain tech choices...
I specifically want a LRU cache to store data in the database to optimize the efficiency of the system. Storage and data is always limited, and we do not want to always hold onto links that aren't being used, or haven't been used for long periods of time.
Try to discuss as many failure scenarios/bottlenecks as possible.
Possible failure scenarios may arise from the server. Too many requests or responses may slow down the system.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
Ideally I would want some way to make the server operations more efficient, and limit the amount of requests being sent to the database at a time. Other methods of caching for the database will also be beneficial, but an LRU cache is all I can think of as of now.