System requirements

Functional:

1. Client gives a long URL, then he will receive a shortened one.
2. Client click the short URL, it will direct him to the Long URL.

Non-Functional:

1. Performance: Able to handle hundreds of requests per second.
2. Availability: Should be highly available to handling requests.
3. Scalability: Should be easy to scale.

Capacity estimation

1. QPS: 10000
2. Peak: 20000

API design

1. shorten URL:
2. endpoint: /shorten
3. method: post
4. request body:
5. {url:https://www.abc.com/longlonglong}
6. response
7. shortUrl: https://short.com/short
8. retrieve:
9. endpoind: /:key
10. method: get
11. redirect to the long URL.

Database design

1. Considering the high volume of requests, and the requirement for future scale, we choose NoSQL, there is no need for schema.
2. For noSql, we set "shortKey" as primary key.

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

1. Client send shorten request to shorten server, server generate a shortKey and store the mapping in the database.
2. Client send request with shortened URL, redirect server get the mapping from database and return the redirect response.

Detailed component design

1. For the shorten server, we choose "Hash" as the shorten algorithm.
2. for each long URL, we do a hash (SHA-256).
3. for the hash result, we choose the first 8 characters.
4. we do a base64 convertion to shorten the HASH
5. we check if it exists, if not, we store it, if exists, we add some salt and do it again.
6. When given the long URL, we calculate the shortKey, if the mapping exists already, we return the same one.
7. On retrieve of the database, we add cache before the database.

Trade offs/Tech choices

1. Use NoSQL for better performance, scalability and availabity.

Failure scenarios/bottlenecks

Future improvements

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