System requirements

Functional:

The system gets an input of a URL and returns a new URL that is shortened.

Non-Functional:

• service is high availability
• the service can endure large scale input
• Latency: write the URL to get a shortened version function that can have latency. But Read a shortened version of the URL and get a new one needs to minimize the latency.

Capacity estimation

scale will be maium 10,000 req per second

API design

We will first start with 1000 reads per second and 1 write per second.

Database design

User search the url in the browser, it will re-direct it into the original URL

user create URL in our system /v1/createURL

High-level design

NoSQL database with the primary ID is the shortened URL which can't be replicated. The data database also needs to include the original URL and other metadata such as timestamps, create user ID etc.

Easier to scale and the shortened URL is the only data that has to be unique. The original URL can have multiple shortened URLs. Because we want to maximize the speed of returning the origin URL and doesn't has another request so far, this arrangement costs lesser space, easier to react, is faster to identify the item row and is easy to scale because it is NoSQL

Request flows

If it is a create URL request, we generate the new URL, return it to the user, and store it in our database. The server will first check if the Cache has the information we need, if so, return it to the server, if not, get it from the database

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?