System requirements

Functional:

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

1. Should be able to shorten URL
2. Visiting shortened URL should redirect to the new URL
3. For each of the minified urls should be different, even for the same link.
4. Users should be able to see the traffic to their shortened urls
5. Users should be able to customize their shortened urls
6. Users should be able to delete their URLs

Non-Functional:

List non-functional requirements for the system...

1. The system should be able to return the shortened URL within 1 second
2. System must ensure that 2 same requests do not generate the same short URL
3. The system should have an uptime of 99.9%

Capacity estimation

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

1. Link generation: 500000 links generated in a day
2. Link visits: 1000000 links visited in a day

API design

Define what APIs are expected from the system...

API:

1. POST /minify-> Body contains url to be shortened and optional custom url
   1. This returns error if the url already exists if they are using a custom url
2. GET /{redirect_id} -> Redirects to the actual website
3. DELETE /{redirect_id} -> Deletes the endpoint

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

This should be immutable

URL Mapping

1. ShortID (Varchar 16) // Cannot be too long
2. Redirect URL (Long URL, TEXT)
3. Created At (Time stamp)
4. Expiry (Timestamp)

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

For the expiry, we can include the current timestamp in the SQL filter.

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

For the cases where the urls expire, there will be a separate job daily to clean up all the urls which contains the data whose url is expired.

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

For scaling server, we can scale it horizontally with a load balancer.

For DB, we can shard the db by short_id and distribute the load.

Trade offs/Tech choices

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

There are different hashing algorithms which we can choose for the algorithm shortening.

We can make use of a normal hashing algorithm for ease of implementation vs base encoding to have a shorter encoding.

Failure scenarios/bottlenecks

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

If the data is failed to fetch from the database, we can still fetch a portion of it from ram.

To improve availability, we can make use of replication for the database, the master can be in charge of writing the data and the slave can be used for read.

If any of the slaves goes down, we can failover to the other slaves/master.

If the server fails, it can also failover to any other spun up server.

Future improvements

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

We can also include metrics and observability into our system to check if there are any hot keys.

For the hot keys, we can increase the TTL for the cache expiry and keep it in cache for longer to reduce the hits to the db.

Add user profile data model and check for deletion if the user has permissions to delete the url.