System requirements

Functional:

1. generate unique shorten url from a given long url
2. redirect to original url when user access the short url
3. track usage statistics for each shorten url

Non-Functional:

1. write requests are 10000 per day
2. read requests are 20000000 perday
3. data exists permanently for popular urls. assume 1% url in all url is popular.
4. data exists 1 year for not popular urls.
5. data size is 200 bytes for a original url.

Capacity estimation

Storage requirement is 1GB:

• original url: 200 bytes/url * 10000 url/day * 365 days/year = 730000 kB/year
• short url: 20 bytes/url * 10000 url/day * 365 days/year = 73000 kB/year
• original url
• original url + short url = 800000 kB/year
• popular url is 1%: 8000 kB/year
• not popular url: 72000 kB/year
• popular url exist permanently (assume 100 years): 8000 * 100 = 800000 kB
• not popular url exist 1 year: 72000 * 1 = 72000 kB
• total storage is 872 MB -> 1GB approximately

API design

POST api/v1/shorten:

• parameter: longUrl: string
• return: shortUrl: string

GET api/v1/shortUrl:

• return: original longUrl for redirection

Database design

Data schema:

• id: int
• longUrl: string
• shortUrl: string
• clickedTimes: int

URL entity represents the shortened URL records in your database.

id is the primary key that uniquely identifies each record.

longUrl stores the original, unshortened URL.

shortUrl contains the generated shortened URL that users will access.

clickedTimes keeps track of how many times the shortened URL has been accessed.

High-level design

There are web server, shorten url service, and databse in this system.

Request flows

original url will be sent to server through REST API endpoints and get shorten url by shorten function in shorten url service.

Detailed component design

Trade offs/Tech choices

Failure scenarios/bottlenecks

Future improvements