Loading...
URL creation:
Short URL usage:
As the given compute requirements are not very high the hardware requirements are correspondingly low. It is more crucial to have the right architecture, like a micro-services architecture which allows to properly scale and serve 6000 users per minute. So horizontal scale is more important than vertical scale.
Per request we need a DB access either for storing an URL pair when an original URL is shortened or for reading the original URL based on the short URL for the redirect. We must ensure enough DB connections are available as this might be more likely to become a bottleneck than serving the requests as such. For the redirect case we should think about introducing a cache to minimize the no. of DB accesses.
Object: ShortURL
Methods:
The main DB table is basically a key value pair with the short URL as primary key and the original URL as value. As the redirect case will happen more often the short URL as key makes sense to allow optimal read performance.
shortURL Table schema:
We need a server who hosts the Client web pages and the URL shortening service. In between shall be a load balancer to balance the request load and implement basic security features like rate limiting as DOS prevention etc.
As persistence of the short URL matching the original URL we need a database. A Cache is also recommended to minimize DB load for the redirect case and increase request 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...
Shorten URL:
User provides the original URL and requests to shorten it. This will invoke the shortURL.create() API which will return the short URL.
When the user enters the short URL in the browser the request will invoke the shortURL.resolve() API which will return the original URL as a redirect, so the browser will open the original URL. This can e.g. be achieved by an HTTP 301 or 308 response.
The key component is the URL Shortening Server which acts as a Webserver and exposed two main API endpoints for creation and resolution/resolve.
The creation of the short URL divides into 2 main functionalities:
The short URL creation requires an algorithm to shorten the original URL and the output must be unique as the original URL. One option would be to use a hash algorithm to convert/encode the original URL. In this case we could even eliminate the whole DB requirement as we could just restore the original URL from the given shortURL by decoding it.
The disadvantage is that with this option the shortURL it seems impossible adhere to the 6 characters max length of the URL path.
So the option chosen here is to create a short unique URL in a manner of a GUID/UUID which is not based on the original URL and store it together as pair with the original URL in the DB to persist this relation and be able to retrieve it when the short URL needs to be resolved.
As laid out in the detailed component design the trade off between a lean simple solution (w/o DB) vs. a conveniently short URL had to be made. In our case we chose the slightly more complex solution for better convenience and user experience.
How to handle original URLs longer than 2000 characters?
Number DB connections might become a problem.
As the key to retrieve the matching table entry from the DB is the short URL, we could use a TEXT or BLOB type instead of VARCHAR(2000) w/o significant difference in performance.
Regarding the number of DB connections we need to perform load tests and see how the solution scales with focus on max number of DB connections. Also we need to analyze and optimize the cache hit rate to make ideal use of it and keep the no. of DB requests and thus connections at a minimum.