Requirements


Functional Requirements:


  • Create a short URL for a given long URL.
  • Return the long URL associated with a given short URL.



Non-Functional Requirements:


  • List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
  • latency should be under 200 ms
  • should be redundant


API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...


GET api/v1/short_url/full_url - this check if the full URL exists return short url, if does not return an error


GET api/v1/short_url/short_url - this check if the short URL exists return full url, if does not return an error


POST api/v1/short_url/full_url - this adds the full url and its shortened value to the DB. If the full url is present return url already present error


UPDATE api/v1/short_url/full_url - this updates the value of the full_url to short url


High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.


the user inputs a url to be converted. this then authenticates the user, otherwise promts to log in. After authentication, the full url as a payload is passed through a load balancer to pass it through the least used server. Before creating a short url, it is checked with the DB(if there is no cache hit), if not present in db it add the short url and long url to the db(where the key is the long url). if this is a success the return the right code back to the user. For redirection the same process through the load balancer is followed then the app first checks for a cache hit , if not it fetched the full url from DB , and redirects. . The server will be using horizontal scalling to ditrubte the load as well as have redunacny.



Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.


The db for storing the url - this should be a no sql db as the input data is simple and the reads are heavily focused, where the read perfromance for the redirecting matters a lot. No sql allowws for easily scaling and very high performance. the data will be stored


The cache used will be redis , thsi will be used in the application layer to reduce the number of times the db is hit. The key will be the the short url as the number of read will far outview the writes so focusing on the perfoirmance of read operation is more important.