System requirements

Functional:

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

1. It should redirect to the original url
2. Daily traffic of 10 millions(10M) of users.
3. URL must have a TTL(assuming 24hrs)

Non-Functional:

List non-functional requirements for the system...

1. System must be highly available.
2. System must be fault tolerance.
3. System must be scalable.

Capacity estimation

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

As per the requirement we have 10M traffic daily.

Traffic per minute = 10000000 / 24 * 60 = 6,944.4444444444 = ~7K rpm.

Since this is a read heavy system then it means we must focus on the reading part from the system.

API design

Define what APIs are expected from the system...

We will be making 2 apis

1. Read api - it will only redirect the user to original link who clicked into the link.
2. It will click on the url given by write api after that it will match into the database and redirect to the link.
3. Write api - It will write into the DB the original link.
4. This will write into the DB the original link along with the unique identifier.

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

For database I am not thinking that this will be very complex. It will simply have a database that will store two values unique identifier (unique_identifier) vs original link(original_link) along with the TTL.

Furthermore we can have a cache mainly Redis. We will store the repeatedly requests into the redis cache.

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

High level design is described in the diagram.

1. Write flow
2. First client will send request with write api. It will pass through the load balancer, since there is large number of requests and the system is distributed then it goes to server where we do our processing and after that it writes data into DB.
3. Read flow
4. Client will send read request after clicking on the same link and it will pass through the load balancer and after server it first checks on cache if it has it or not.
5. If yes then it is a cache hit and if not then it is a cache miss.
6. If cache miss then it will search into the database and if found then it will write into cache and return it.
7. We can handle those urls whose TTL has expired by simply deleting them and we can do it using cron job. Those urls whose TTL has expired then delete those.

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

For Database I will be using Mysql, for cache we will be using Redis. We using Mysql because the data that is present to us is more of a structured data and Mysql is very efficient in that case. Also I picked Redis because it is widely used cache as it is open source and gives faster response. We can also use in memory cache as well, depending on the requirement.

Failure scenarios/bottlenecks

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

There can be some bottleneck scenarios like

1. If a user need the url for very long then it is not possible with our current system.
2. If we are using hash function then there may be a chance that 2 users may have different link but have same hash code then one will override the other.

Future improvements

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

Improvements

1. If the database is too large then it will take time to access the record from it in that case we can distribute the database so that a single node is not handling all the load.
2. We can also ask the TTL from the user itself rather than assuming it.