System requirements

Functional:

• User can input the full URL and can get the short URL
• User can specify expiration date and customize the URL alias
• The system can track how much traffic come to each url

Non-Functional:

• Scalability - the service can handle the load in case that there are increasing number of loads
• Availability - user can always access to the url If it didn't expire.

Capacity estimation

• if we're expecting around 1 million users and each user creates about 5 URLs in average, so we'll have 5 million URLs in the system
• User access each URLs estimately 10 times a day so it will be around 50 million requests a day
• Each URL along with metedata may takes about 1KB, so we'll need around 5GB for 5 million URLs
• The system may grow to 5 million user in a year

API design

• create URL - full URL, expiration date(default if not specify), URL alias
• get full URL with the shortened one

Database design

Firstly, we need to have the table to store the information of URL

URLDetail

• url_id: full URL (Primary key)
• shortened_url
• alias
• author: user_id (Foreign key)
• created_date
• expired_date
• click_count

the user table for storing user information

User:

• user_id
• name
• email

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

Firstly, the client will get input URL from the user with other optional value such as expiration date, alias then will call the creation api to create shortened URL. In this service, we should handle logic for generating URL to make it unique and map to the full one. After finished, the service should return the shortened URL. When user used that URL to access, the client will call get api to redirect to the corrected 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...

To make our system more efficient, we can consider scalability. In this case, we might need to do horizontal scaling and use load balancer to distribute the request through many servers.The algorithm we should use in this case can be round-robin strategy because we can handle each request statelessly

Another part is to use Kafka queue to help when we create the URL. we can publish the change to topic and the read service can subscribe and store that information into DB.

For read service, the urls that are stored can be many times when many users access so this can generate amount of queries to the DB . What we can do is to implement cache such as redis by storing key as shortened URL and value as full URL so we can access to the data quickly without interact with database.

Trade offs/Tech choices

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

Capacity limitation - If we have a lot of URLs, we may not able to store every URL in the Redis. We can have an algorithm to select only the recent one that just created with less expiration date or the one that have many number of clicks

For consistency, the user should get the url which map to the corrected url so we should consider use strong consistency model even it might introduce latency but it will improve user experience and prevent them to turn around to other system.

Failure scenarios/bottlenecks

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

Database Performance: If the database can't handle load of write or read operation, it can become the bottlenecks

Cache Efficiency: If cache hits are low, the application need to access the database frequently

Network latency: High latency in network communication can slow down request handling

Future improvements

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

• Implement load testing to make sure how frequently request the application can handle to determine scaling option
• implement monitoring and profiling tools to help specify which database query take the most of time