System requirements

Functional:

Creating short-url

• System able to create short-url when user provides long-url
  • POST short-url/

Redirecting

• User able to visit when user provides short url
  • GET short-url/?id=hash

Non-Functional:

• High-Availability: user need to access short urls even when system performing low or none.
• Scalability: system need to perform well when unusual traffic increase.
• Performance:
  • user need to redirect to original url with 100ms
  • Short url create under 200ms

Capacity estimation

Estimate the scale of the system you are going to design...

Creation of short URL's:

• 200 requests/second
  • (200*60*60*24) => 17,280,000 requests /day

Redirection of Short URL's:

• 2000 requests/second
  • (2000*60*60*24) => 172,800,000 requests /day

Storage requirements

• id (Consistent Hashing) = 8 bytes
• long-url = 150 bytes
• short-url = 20
• created-time = 20 bytes
• user = 8 bytes
• expirtion time = 20 bytes

226 bytes roughly 256 bytes / request

DB Storage

• 200*60*60*24*256 = 4.4 gb/day
• 4.4 GB/Day * 365 = 1.61 tb/year

API design

POST short-url/

- input: a long url

- Output: a short url

GET short-url/?id=hash

- input: a short url

- output: redirects to original user url.

Short-url Service:

- User will provide long-url through api.

- The system will generate consistent hashing. This will id for long-url

- Along with id will store in Database.

- Return to user short-URL including parameter with id.

Redirecting Service

- when user clicks short URL.

- retrieves the the long URL with search of id.

- if id retrieves success then redirects to original URL

Database design

For Database SQL Database.

Storage requirements

• id (Consistent Hashing) = 8 bytes
• long-url = 150 bytes
• short-url = 20
• created-time = 20 bytes
• user = 8 bytes
• expiration time = 20 bytes

High-level design

Create Short-URL:

When client request to create short URL request. API Gateway will routes to short-URL service. Here in server short-URL created using consistent hashing and sent to store DB. Once DB success saves to cache for time limit. Then redirects to client with short-URL.

Redirect Service:

When client enter short-URL then API-Gateway routes to redirect service. Redirect service try to find cache if found redirects to original link. Otherwise try to find on DB if found then set to cache then redirects to original link.

Request flows

Create short-url:

• Client invokes short-URL API. Request routes to load-balancer to one of servers.
• Server will generate the hash for URL and stores in DB.
• Once DB success server to insert in cache for quick retrieval.
• Then response return to client.

Redirect:

• Client invokes short URL.
• url routes to one of server from load balancer.
• Server will check first on cache. If success redirects otherwise to look on db and redirects.

Detailed component design

API-GATEWAY

- load balancer

Load balancer will be used send request apporiate to serves

- servers

These server will handled short-url and redirect services

Storage

- Database

Database responsible for storing records

- cache

Temporary storage

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

• cdn
• mysql vs dynamo db

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?