System requirements

Functional:

1. same url generates same tiny url irrespective of different users requesting
2. shortened url is 6 characters long
3. assuming store for 10 years
4. redirect to original url if tiny url presented

Non-Functional:

1. Highly available
2. Scalable
3. Performant
4. Eventual consistency

Capacity estimation

1. Assuming 10000 unique users per day and each user doing atleast 3 unique shortening requests - 30,000 urls per day.
2. If each url is ~ 5kb - then we need 150,000kb/day or 4500,000kb/month ~ 5GB or 60GB per year.
3. Considering 3 replicas- 200GB of storage for urls

API design

1. GenerateTinyURL(string longURI)
2. RedirectToOriginal(string tinyURI)

Database design

URIMetadata table

• longuri (index)
• createdate
• location

URIMapping table

• longrui (index)
• tinyuri (index)

High-level design

The system will contain a load balanced set of web servers hosting 2 micro-services one for generating url and another for redirecting. Also a database layer to store the url information.

Given there will be more reads than writes, we will have a read replicas of the database. Writes goto to the Master and reads or redirecting calls goto to read replicas.

Database will be a PostGres database.

A cache layer holding the url mappings with a TTL of an hour can help with look ups before generating urls and for redirection requests.

Request flows

GenerateURL API flow

1. User calls Generate URL API and passes in a http url
2. Check in Cache if a tiny url for this url already exists, if not pass to web server
3. GenerateURL API will validate the url, check in DB if a mapping exists, if not generate a new unique tiny url
4. Store new url and mapping in DB (Master) update cache and return

Redirect URL

1. User calls redirecturl API with the tiny url
2. API will validate if this url has a mapping and is still valid
3. Redirects user to that url

Detailed component design

GenerateURL service will

1. verify if the long url is valid, if a tiny url already exists for it
2. if valid and new, then hash the url and base encode the hash to generate a unique alphanumeric code of 6 characters
3. Stores in the database the url metadata and mapping
4. returns the tiny url

RedirectURL Service will check if mapping exists and redirects user to the long url.

Cache layer will help look up tinyurl for longuri or vice versa for either services

Trade offs/Tech choices

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

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