System requirements

Functional:

1. System should be able to take in a long url and shorten it to a short url
2. System should be able to redirect users with the short URL to the long URL
3. All short URLs should be unique

Non-Functional:

1. System should be highly available, and able to scale as the number of request increase

Capacity estimation

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

Assuming that each user creates 2 URLs and assuming we have 100,000 users we'll need to be able to handle at most 200k request per sec for URL creation. But it is unlikely that each user is creating at URL at the same time. Assuming the traffic is uniform, and we have able 50K URL creation request per sec.

The other consideration is clients requesting short URL and we need to redirect the user to the long url. This will be where the majority of our traffic comes from. Let's say the ratio between the creation and redirection service is 1 to 3. So our request per second would be 600k at most and 150K during normal operation

API design

Define what APIs are expected from the system...

shortener.com/create - this API is responible for creating the url. It will take in a long url and return a short url

shortener.com/redirect/{short_ul} - this API is responible for redirecting the client to the long url

shortener.com/delete - this API will be responible for deleting short URLs from the database

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

create table urls(

long_url VARCHAR

short_url VARCHAR(8)

PRIMARY KEY(long_url)

)

the table urls stores the relationship between long_urls and short_urls

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

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...

short url creation service

1. Client makes request with long URL and service responds with a short URL

short URL redirect service

1. Client makes request with short URL and is redirected with the short URL

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...

Hashing/Encoding

1. To encode the URL I will use BASE62 encoding

Database Design

1. We will have one table in the database called URLs. It will be structured like so

create table urls(

long_url VARCHAR

short_url VARCHAR(8)

PRIMARY KEY(long_url)

)

Trade offs/Tech choices

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

1. I went with using a cache instead of using

Failure scenarios/bottlenecks

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

Database bottleneck

1. To help this service scale we would place a cache in between the service and the database. The server would first make a request to the cache and upon cache miss it will then make a request to the database for the URL. Because our application is very read heavy, I anticipate the database being the biggest bottleneck.

Server bottleneck

1. To handle server bottleneck we should place a loadbalancer in between the servers and the client the loadbalancer will distribute request to the servers and spin up new servers as traffic increases.

Future improvements

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