System requirements

Functional:

shortening a long URL into a shorter string

redirect shortened string back to their original URL

Non-Functional:

handling high volume of URL shortening requests and redirects

maintaining data consistency and deduplication

Capacity estimation

I am not expecting extremely high scale given the system's overall low workload, high number of alternatives, and it being a non essential service for most users.

API design

Suppose the APIs are HTTP, two APIs are at least necessary:

1. shorten: can be either GET or POST, takes in an original url and responds with a standardized shortened url
2. redirect: redirects a shortened url into its original url

Database design

key-value stores with fast write and read speeds is great for this system. Redis or similar services are a good choice in this area. This allows for easy query from the shortened url to the original url.

High-level design

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

Request flows

There are two major flows:

1. The user using the service inputs their url that they wish to shorten on the UI, the url is sent to the server, where a generic string is generated and used as the shortened url, e.g. https://youtube.com/klasjdoiqwejio -> https://tiny.url/abcde. Both are stored in Redis where the tiny url is used as the key and the original url is the value.
2. Upon query of the shortened url, the server is accessed and directly queries the original url from Redis, then redirects the user to the original URL.

Detailed component design

The url generation can be done via a random generation, genetic hashing algorithm or a combination of both to ensure efficiency.

Trade offs/Tech choices

There aren't that many tradeoffs as it is a relatively small system. One thing that may be different than more standard systems is the use of Redis as database, which may lead to unfamiliarity among devs and potential more work as the system scales. However, its fast query nature is arguably more important given that we would optimistically match the loading speed of entering a shortened url vs the original long url.

Failure scenarios/bottlenecks

Given the small systems, the failure scenarios are relatively rare.

1. If the server is down, then unfortunately the shortened url will not work and there is not a viable solution until the server is back up.
2. A bottleneck may be that if there have been already many generated short urls, there may be an issue with a repeated generation -> verify whether the generated url exists in the db -> re-generate cycle that leads to poor performances when generating. A log should be kept an eye on to ensure that whether this bottleneck ever occurs, as it is sign that our system needs more methods of scaling

Future improvements

A few notable things need to be considered, especially if higher volumes are anticipated.

1. Redis is a single threaded component by default, higher volumes may imply that distributed servers of Redis, or other key-value stores more suited for distributed uses are needed.
2. url mapping: the shorter the shortened url, the less alphanumeric combinations are possible. A random generation or a generic hashing algorithm works well for a shortened url until the volume gets very large, where either we need to implement policies such as each shortened url lasts a limited amount of time, or lengthening the shortened url.