System requirements

Functional:

1. given a url , system generates the tinyurl.
2. the tinurl code should be around 5 characters.
3. the new url stays in the system for about 5 years.

Non-Functional:

1. latency of url redircts to be single digits ms.
2. latency of url creation could be bigger.
3. 1 mn new urls per month.
4. 1 bn requests on the new urls per month.
5. highly available system.

Capacity estimation

• system will need to save about 60 mn urls at a time.(60,000,000)
• the qps for creations will be: .3qps
• the requests would be around: 300 qps.
• we could use alphanumeric char to create the url. using 8 alphanumeroc digits should give us : 36^8 spaces: 1,000,000,000 * 3.6^8
• this space gives us ebough for 5 years and beyond.
• storing 1 entry should take about 500 characters per entry. which would mean that we require: 150B*60mn = 30TB for 5 years.

API design

Define what APIs are expected from the system...

we would create 2 APIs for the system:

1. createURL(String url) returns shortened url;
2. getURL(String key) return the long URL.

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

the data model to be used here can be very simple. with 1 table having columns like:

1. username
2. key
3. url
4. createtime
5. expiretime

High-level design

At a high level requests come to our system where a load balancer sends it to either getURL, or, createUrl based on the api.

keyGeneration service:

i would create a service which generates keys unique and free keys which can be used by the servers to generate shortURLs for. the kjeys can be based on monotonically increasing pattern, since they are being generated at a single place. All servers can get a buffer of 100 keys every time they start up and as they use it , request another batch.

createURL:

the servers handling createURL get the url from the user, they get the key from the buffer of short keys. they create a DB entry for the given key.

getURL:

the get URL method goies to a local CDN first. if the CDN does not have the key, that request goes to server, where it is fethed from a REDIS cluster, if not available, data is loaded from DB onto cache and then returned.

Request flows

for getUrl:

the request first goes to CDN, then to server, then to Redis and then to DB.

for createUrl:

the request goes to an LB then to a server and then to DB.

for KeyGen:

the request goes from client to keyGen service.

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

we used CDN here to make sure that the response is very efficient and quick.Redis is also used for the same purpose.

Failure scenarios/bottlenecks

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

KeyGen service might become a bottleneck.

Future improvements

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

scaling the keyGen service