System requirements

Functional:

• The system takes a URL as input and creates a shorter URL directing to the same website.
• The system allows users to set an expiration time to their links. If not set by the user, the system sets an expiration time.
• Users should be able to click the link and be redirected to the website

Non-Functional:

• generating a short URL should be quick
• this is a write-heavy system
• some URL addresses are more popular than others.

Capacity estimation

Assume 1 million short links are generated every day

Assume 10 million active users

Assume short URL length is 8 characters=8 bytes.

every month 30 million short URLs are generated.

Need monthly storage of 30*8 = 150 million bytes

in a year we need 150*12=1800 million bytes

API design

"read" API and "write" API.

Read API: redirects to the URL address requested by querying the database or the cache.

Write API: creates a new short URL. Checks against the database that it is unique. If it is not unique, it will generate another. Stores the new short URL in the DB and returns in to the client.

Database design

a NoSQL DB that does not allow duplicates with short URLs as keys and their matching long URLs as values.

We can have 2 tables - a URL table and a users table.

The URL table will have a shortURL key and will store the longURL, creationTime, expirationTime.

The users table will store the user's name, email, password.

High-level design

The client inserts a URL and is being redirected through a load balancer to the write API. the write API generates a short URL and checks if it already exists in the database. if it does it generates another and makes sure that it is unique. The new URL is written to the database and returned to the user.

When a user clicks one of the generated URLs, the read API will be in use. It will query the cache and look for the URL. If it is not there, it will query the DB. The correct address will be returned. Using a DNS server it will be translated to an IP address.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Trade offs/Tech choices

chose a NoSQL over SQL because it is more flexible and we do not need any complicated joins.

Failure scenarios/bottlenecks

Bottlenecks can happen when writing to the database or at the load balancer that manages all the traffic from the clients.

We can use sharding to scale the database or have master-master replicas (since the system is write heavy)

Future improvements

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