System requirements

Functional:

1. User can create a shortened URL for an URL.
2. User can get the original URL for a shortened URL.

Non-Functional:

1. The system should be highly available (availability > 99.9%)
2. The latency should be low (P95 < 500ms)
3. Uniqueness (no two original URL map to same shortened URL)

Capacity estimation

For create, assume 10M user 10 request per day.

For read, assume 100M user 100 request per day.

Assume avg ori URL is 130 char long and avg shorted URL is 20 char long.

Storage estimate: (150*2)*10M*10 =30 GB/day, 10 TB/year

Write per second: 10M*10/24/3600 =1 K/s

Read per second: 100M*100/24/3600 =100 K/s

API design

post /v1/urls

{

originalUrl:string

} ->

{

shortenedUrl:string

}

get /v1/urls/{shortedUrl} -> orignalUrl

Database design

Account

• AccountId
• Contact
• Tier

Url

ShortenedUrl

OriginalUrl

AccountId

CreatedTime

High-level design

For get url, user can hit the backend service via APIGateway and load balancer. The RetriveURL service will return the original URL.

For create url, user can hit the backend service via APIGateway and load balancer. The ShortenURL service will create a unique shorted URL for the given URL. The newly created URL will be saved into database.

Request flows

High-level design

For get url, user can hit the backend service via APIGateway and load balancer. The RetriveURL service will return the original URL.

For create url, user can hit the backend service via APIGateway and load balancer. The ShortenURL service will create a unique shorted URL for the given URL. The newly created URL will be saved into database.

Detailed component design

This is a read heavy system, we can support the scaling via replica. Strong consistency is not needed here, user can get the shorted URL after a few seconds. Database replica can be added to scale up ready URL service. Since the mapping does not happen often, cache can be introduced between retrieval service and the database.

How to guarantee uniqueness for each URL. We can use timestamp(ticks as u64 which is 8 bytes + a UUID (128-bit, 16 byte), it will be 24 byte for the shorten URL. It can be then base64 encoded to string. The collision rate would be so low that we can consider it will never have two URLs mapping to same URL.

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?