System requirements

Functional:

1. Given large url's, shorten large urls to short urls
2. Given a short url, redirect to a large url.

Non-Functional:

1. System should be available.
2. System should be scalable.
3. System should be partition tolerant.

Capacity estimation

Estimate the scale of the system you are going to design...

API design

host - www.bitly.com

1. POST /v1/shorten -> returns a shortened url to the user.

{

"url":""

}

2. GET /v1/shorten? url=? -> Returns a long url mapped to short url.

Database design

1. User (Id,Name,etc)
2. Url -> (id,longurl,shortUrl)

In Cache -

Key: LongUrl

Value: shortUrl

High-level design

1. The client will provide a long url from the browser to the url shortening service.
2. The url service will generate a short url from the long url and store the mapping in the DB.
3. Url shortener can employ multiple strategies to shorten the large url, for eg algorithms like SHA or MD5 can be used. For simplicity we can choose base 62 encoding for shortening the long url to short.

Request flows

1. The POST request to shorten the url will go from client to Url shortener service which will store the mapping between short and large url in the database.
2. The same mapping will also be stored in the cache, so if another user sends shorten request for the same long url, the long url can be returned from the cache.
3. When the url clicks on the returned shortened url, the user is redirected to the long url.

Detailed component design

1. We can use cache like Redis to store the key-value pairs where key will be the long url and value will be the short url to speed up the post requests.
2. We can use MySQL DB in master slave replication where master will accept the writes and will propagate the writes to the slaves asynchronously. Slaves will accept the read queries.
3. Since this is a write heavy system, with not much consistency requirements we can use master-slave replication.
4. We will first write to cache and then to DB, so to speed up the read process.

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

1. Services like Auth and rate limiting can be implemented either as part of Url shortener or a API gateway service can be used for the same.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?