System requirements

Functional:

1. Given a long url, return a shortened url like abc.com/0001, clicking on the shortened url, the browser would redirect to the original url.
2. Providing statistics data like the how many clicks on the shortened url.

Non-Functional:

1. Scalability
2. High availability
3. Low latency

Capacity estimation

Number of Users: Let's assume we have 10,000 active users using the URL shortening service.

Number of Links per Day: On average, each user shortens 5 links per day. This would result in a total of 50,000 links generated daily (10,000 users * 5 links per user).

Average original links size: 10KB

QPS for shortening: 50,000 / (24 * 60 * 60) = 0.57

Read QPS: 35

Storage: 50000 * 365 * 5 * 10 K = 891 GB

API design

Shortenize original link:

/upload/link

payload:

method: post

{

"user_id": string

"original_link": string

}

response:

{

"status": int

"short_url": string

}

/redirect/link

payload:

method: get /?link={shortened_link}

response:

{

"original_url": string

}

Database design

I want to have a key value store like DynamoDB

{

"short_link": tinyurl

"original_link": originalurl

}

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

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?