System requirements

Functional:

• request a shortened URL
• redirect a user to an original URL by a shortened version

Non-Functional:

• shortened URLs lifetime
• cache for redirection
• hashing and collisions

Capacity estimation

• 16B per shortened URL
• 256B per original URL
• 2B per timestamp

API design

• POST body=<normalized-original-url>
• GET query=<shortened-url>

Database design

• NoSql persistent DB, like Redis
• 
  
• Each record would include
• key - shortened URL
• timestamp - date of the creation
• original url

High-level design

We have a pretty simple design:

• a load balance
• shortener service, which handles URL shortening requests
• redirection service, which handler user redirection requests
• cache for shortened URL keys
• cache for

Request flows

We have two main flows to cover:

• a request for shortening an URL
• a request for redirection with a shortened URL

For the first one a request first goes to a load balancer and is dispatched to a proper instance (taking current load into consideration) of a shortener service, which generates a new one, puts it in the DB. Then it returns the result to the user.

For the second case a request also starts from going to the load balancer, but then it gets routed to a redirection service. It first checks its own cache and if the record for the shortened url cannot be found goes to the DB and then either returns an error to the user or puts the original URL to cache and redirects the user.

Detailed component design

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...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

• if a user tries to request a redirect to an expired on non-existent shortened URL, we will just return 404
• we can occasionally miss the cache for a record that was added recently and go directly to the DB, which doesn't break consistency, but can be a performance hit

Future improvements

• we can later add a possibility of requesting custom shortened URLs
• we will need to cover APIs and services with different metrics for analytics, performance monitoring, etc.