System requirements

Functional:

• Generate a shortened URL for the URL that has been given by the user as input.
• Ensure that no 2 inputs map to the same shortened URL.
• the shortened URLs will be associated with an expiration time, which will be 365 days after which the URL will stop working and user will have to generate a new shortened URL.
• Ensure that the shortened URL redirects to the correct original URL.
• Maintain a history log for the user to keep track of how many URLs a particular user has provided.

Non-Functional:

1. The system should be highly available, considering 99.999% system availability.
2. The system should be fault tolerance.
3. User should be able to get the tiny URLs with minimal latency.
4. System should have rate limiting to avoid the user bombarding the system with requests.

Capacity estimation

Considering a total user base of 10 million users, we can consider DAU as 1 million.

daily each user provides 5 URLs to the system to be shortened.

considering for each URL if we need 1 KB of space to store the tiny URL, the original URL and the time details we can have 1 million * 5 * 1 KB of space required on a daily basis.

We can consider peak load all at once hence 1 million requests per second of peak load.

API design

1. generate-url : This API would take the original URL from the user in the payload and will provide the generated shortened URL.
2. redirect : This API would take the tiny URL as input and would help the user get the original URL to be redirected to.
3. view-history/{userId} : This would give the details to the user of the URLs they have provided to the system till date.
4. get-expiry-date : This API would take the tiny URL as input in the API payload and would return the date of expiration of the URL.

Database design

1. We can make use of a relational database such as postgres in order to store and retrieve the details of the URLs for the user.
2. We will have a user table which will store the user specific metadata such as username, first_name, last_name and an id user_id column which can be a UUID.
3. We will also have a table url_mappings which will have the user_id from the user table as foreign key, this table will store the mapping of the original_url and tiny_url and a column called expiration date, beyond this date the URL will not be accessible to the user.
4. Since this will be a read heavy system we can have a replica set system where we can have 3 read replicas and a single writer.
5. We can also have sharding of the database on the basis of the location of the user which will help us to scale effectively depending on if the application has global usage.

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

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?