System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. System should be able to generate unique short url for a given long url
2. Given a short url, system should be able to generate response to redirect to corresponding mapped long url
3. It should be possible to customize short url name
4. System should have additional monitoring service to track metrics like number of clicks on short url - helpful for data analysis and business modelling

Non-Functional:

List non-functional requirements for the system...

1. Scalable - system should be able to generate millions of short urls
2. Available - system should be highly available. Even if some nodes are down, users should still be able to generate short urls or redirect to original urls
3. Low latency - urls should be produced at no additional bottlenecks

Capacity estimation

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

Assuming 100 millions urls are shortened per day:

1. Each url being 100 chars long i.e. 100 bytes per original url
2. Each short url is 50 chars long i.e. 50 bytes per short url

QPS = 100*10^5 Kb per day

QPS ~ 1000 Kbps ~ 1 Mbps

Storage requirements: 150 bytes per query

Total = 1.5 TB per day

Total storage for 1 year = 1.5 * 365 ~ 450 TB

Total storage for 10 years = ~4500 TB ~4.5 PB

API design

Define what APIs are expected from the system...

Input to shorten API should be original long url string and output should be unique short url

shorten(original_url)

Input to redirect API should be short url string and output should be redirect response to original url

redirect(short_url)

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

SHORTURL data model should have primary key ID, original url and corresponding unique url_id

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

Client sends request which reaches front-end server. Front-end server parses request to understand the corresponding requirement - shortening or redirecting. Front-end server forwards request to corresponding API.

When the request reaches URL shortening API, it determines if original string is already shortened from cache or database. If it's not found in neither, it creates a unique short url and creates entry in database for original url and created unique short url.

When the request reaches redirect API, it looks up original url corresponding to requested short url, prepares a 301 (moved premanently) status code response and sends it back

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?