System requirements

Functional:

• input a longer url
• outputs a shorter url
• store

Non-Functional:

• user inputs a tiny url and should be returned the original long url
• user inputs original url and should be returned a shortened url

Capacity estimation

we are estimating 100 million user traffic per month, which means around 3.3 million traffic a day, which is around 40 per second average. but taking in different traffic estimation the system should support 400 request per second traffic.

we also need databases to store the shortened url and

API design

• url to shorten a url:
• POST: /shorten/<url>
• returns a shorted url
• GET: <shortened url>
• returns the long url

Database design

table:

URL

int id, increment by 1, unique

string original_url

string shortened_url

date_time, created_time

High-level design

client -> local server -> local cache -> central database

Request flows

client sends request to shorten a url, the request goes to the server, server checks cache if shorten url was created for the url recently, if yes it returns the shortened url, if not server creates one using algorithm and saves it to the database and cache, server then returns the result to the client

Detailed component design

cache: since there are clients around the world, we need to think about request time and make sure the returned values for the same url is unique. therefore, we should have copies of databases in different regions of the world and update it every minute.

we should host the servers in multiple regions as well and make sure everywhere it uses the same algorithm to create the shortened_url, this way we dont have to worry too much about multiple requests making different shortened url for the same original url

Trade offs/Tech choices

having a standard algorithm/hash that computes the same distinct shortened url means anyone can create the url if they have the algorithm, but since the original url isn't sensitive, it is ok to use this technique

also hosting servers and having copies around the world means we have to account for cost and discrepancies, trading off for faster service time.

Failure scenarios/bottlenecks

there may be bursts of request in a particular region, so we should have enough computational power to serve large loads of requests in a short time

also different regions may have distinct sets of urls they would like to shorten, for example, urls in north america may differ vastly with the ones popular in asia, thus having database sync may not be as important or effective

Future improvements

depends on actual usage, server power and database locations can be tuned