System requirements

Functional:

Since this is a URL-shortening service, we would need:

1) A Hash function for shortening the URLs. this would need to support a lot

Non-Functional:

According to the CAP theorem, Capacity is more important than availability as we could have a lot of URLS.

Capacity estimation

I'm assuming that it will be a large system since it can have a large number of users and generate a large amount of URLS, so 100000 qbits,

API design

URL hash shortening function. This would be a REST GET request that returns a shortened URL.

Database design

For databases, I will use a NoSQL database like mongodb. this is because data is not related.

High-level design

Client -> load balancer -> REDIS cache -> server -> database (mongoDB)

Request flows

Client will enter a URL in the textbox, and then it will send a request to the server. The server will then return a shortened URL. There will be a cache (REDIS) that has saved already calculated URLs. If a shortened URL already exists, then a cached shortened URL will be returned instead of creating a new one.

Detailed component design

The hashing function will work as follows, take each URL, and map each character to a different prime number. the product of primes is guaranteed to be unique, so use that product of primes as the key, and the shortened URL as the value. The data structure of the cache will be a key-value store similar to a hashmap using REDIS.

Trade offs/Tech choices

I added some overhead with a cache, but it will payoff assuming that there will be a lot of duplicate entries. this is likely to be the case ,as there are many users who might link to the same thing, like when something is viral.

Failure scenarios/bottlenecks

One could reach max capacity, but sharding should be able to take care of this.

Future improvements

I would add authentication and favorites so that users can save and share their relevant URLs with other people.