total users: 10 to 100 million users;
acitvet users: 10 to 20% of total users
link activity: 1 to 5 links per day by active users
link usage: on avg 50 clicks per link
total users: 100 million users
activ users: 20% * 100 milion users = 20 million users
link activity: 5 * 20 millions * 3600 = 100 millions / 24 * 3600 =
4 millions / 3600 = 4000000/3600 =1000 qps for activity
link usage: 1000 * 50 = 50000 qps for usage
API consists of two methods - one for shortening URL and the second one for redirecting from short ulr to the original one
shorten(strign)
PUT request to fetch short url for given long url if it not exists
redirect(string)
GET redirects the shortened url to original long url
Tiny url will be web app which will store its content in cdn
Because of scale multiple web servers will be used, LB will be responsble for managing the trafic betewee client and web server; user comunicate with load balancer and does not see web server;
Behind web server there will be cache which provides fast access to shoertened links; if the link is not in cache then we check if db - if db does not have it it is created and saved both in db and cache;
cache can be used with some expriation time (how long the key and value will be stored in cache) Redis for instance
at the end there will be RDB (PostgreSQL) which will store mapping between link; RDB is used to guarantee no duplicates. it is potentail long term feature - if we want to add new features like user management etc
for shortening url hashing function will be used; if the shortened link is not present - first in cache then db we generate new hash; hash should be genarted not only based on its original link but also some rand value so the function returns new link for every invocation
since no reads to writes ops is 50x bigger we can distribute db to master-slave architecture where slaves will be read only dbs and master db will be write onlny;