System requirements

Functional:

1. Input original URL
2. Generate corresponding short URL
3. Database to store the original URL and map the short URL to the original URL.
4. URL length to be between 8-16 characters.
5. URL name should end with bit.ly, owl.ly, and short.io.
6. Regex validation to validate the input URL.
7. Proper hashing technique to generate unique and collision-free short URLs.

Non-Functional:

1. High availability
2. Scalable
3. We will use microservice architecture to make the components independent of each other and individually scalable.

Capacity estimation

We expect 1 million users to visit us every day, so approximately 1 million tiny URLs will be generated every day which means 1000000/(24*60*60)=12(approx) tiny URLs being generated every second.

API design

The APIs to be included in the design include:

1. /home or the default page where the user chooses which service they want.
2. /signup or /login pages will be used to authenticate and authorize a particular user.
3. /tinyurl/:id- this is the page where the user with a user ID (id) enters the original URL to generate the TinyURL.

Database design

We would use a NoSQL database like Cassandra/MongoDB/HBase to store the URL information, number of clicks, its corresponding tinyurl, start time, end time, etc.

Also we need to store the user login information like username, email, password, etc in another database.

The Schema for URL information storing database would somewhat look like this:

TinyURL:

id, original URL, start time, end time, tiny URL, no of clicks, user id

The Schema for the user login table would look like this:

Users:

user id, username, password, email

High-level design

First, there should be the client side, which connects with the load balancer, cache. The load balancer connects with the backend server, which in turn connects with the MongoDB database. The database could connect with analysis tools like Hadoop, and Pyspark. We can also use AWS technologies like ElasticSearch for efficient searching operations, and Lambda for automated load or traffic handling. We use base 62 to shorten url in the backend

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

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain 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?