System requirements

Functional:

1. User provides the long url ,convert into short url.
2. user searches with short url redirect to long url.

Non-Functional:

1. Highly available.
2. scalable and performance.

Capacity estimation

1) 1 Million write and 10 Million request per day

read QPS = 10 M/24*60*60 = 100

Write QPS =10

2)Consider 100 bytes of url length for 10 years:

1M* 10years*365=36.5 billion records

36.5billion*100 bytes= 3.65 trillion

API design

1) Post api/v1/shorten

Authentication bearer token JWT

longurl:string

return shorturl

2) Get api/v1/shortUrl

Authentication bearer token JWT

301 redirected

Database design

1)Url Table

UrlID:UUID

shortUrl:String

longUrl:String

High-level design

Request flows

Short URL Creation :

Client -> LB -> Web Server -> Shorten Service -> Write Database -> Read Replica

Fetch Short URL

Client -> LB -> Web Server -> Short URL Service -> Cache -> Read Replica

Detailed component design

1) Shorten Service : For shorten service one of the way to create the short url is based of MD5 algorithm and in case of Collison we add the random string and then again create short url based of MD5.

Another way is the base64 algorithm in that we first generate the UUID of 7 digit based on long url and then do Base64

Third approach is to use Redis and use sorted set data structure to avoid collison .

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?