System requirements

Functional:

As a user I would like to provide the original url and get a shortened url

As a user I would like to provide the shortened url and navigate to the original url

The url should be as short as possible

As a user I would like to provide a custom alias to the shortened url to remember or share easily

As an analyst I would like to know how many times the url has been used for analytics purpose

Non-Functional:

The latency to get the shortened url should me as minimal as possible like 100ms

The system should be highly available

The system should be highly scalable

The system can be trade off with consistency for high availability

Capacity estimation

assume there is about 200 requests per second, then that's about 17.28 million request per day.

assume there are 20000 request persecond, then are 1.73 billion requests per day

API design

HTTP

1. POST CreateShortenedURL(original_url: string, alias:string=None) -> string
   1. {"original_url": "https://www.abc.com/defijslasdfds"}
   2. {"shortened_url": "https://www.xyz.com/123456"}
2. GET GetOriginalURL(shortened_url: string) -> string
   1. {"shortened_url": "https://www.xyz.com/123456"}
   2. {"original_url": "https://www.abc.com/defijslasdfds"}

Database design

Design a table with a specific uuid, the shorten url as another column, the original url as the other column

High-level design

A client calls the service to generate url, the server that generates the shorten url and store in the database. When doing redirect, the client send the short url to server and server returns the longer url and client has a function to do redirect itself.

We can also have a cache in between server and database for faster retriver of the result.

When there is no url exist, server will simply give error response and client need to know.

Request flows

POST request goes from client to server, server generate shorten url, and write to database and cache using write through method. When doing get, client go to server, server retrive from cache first, if not found, go to database to find the mapping between short and long url and return long url.

Detailed component design

The server can have multiple instances to handle the reuqests coming from the client. And the server will use some algorithm to genereate the short url. The database will consist of 1 table and have reader and writer server.

Trade offs/Tech choices

Using cache to speed up the retrival. We have more read than writes. So we need to have the cache to support read faster. The server can write through data to db and cache to update things faster.

Failure scenarios/bottlenecks

1. We are not keeping track of used hashes effectively,
2. We are making a lot of DB calls on create, lowering write latency
3. The hashes ran out so we shorter urls aren't short anymore.
4. System can go down if someone very famous posts a URL that generates a lot of traffic
5. We have a few components that introduce SPOF

Future improvements

Assign more cache instances

1. Real-time Analytics: analytics service to provide real-time data.
2. Link Customization Options: Expand customization options, such
3. Integration with External Analytics Tools: Allow users to integrate their short URLs with external analytics tools like Google Analytics.