System requirements

Functional:

• Shorten a url
• Unique url
• 6-8 characters

Non-Functional:

• 200 req/sec POST
• 17.28 millon short URLs created per day
• 20,000 req/sec GET
• 1,728 million per day GET req
• Prioritize availability
• Fault tolerant

Capacity estimation

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

• 256 bytes per entry
• 256 * 200 * 60 * 60 * 24 storage required per day = 4,42368Gb per day
• 15,948 Tb per year

API design

• Create short URL:

POST /create

body: originalUrl

• Redirect URL:

GET /{url}

Responds: 301 redirect to original URL

Database design

URL:

• shortURL
• originalURL
• timestamp

High-level design

Request flows

Create short url:

The user requests a short URL, providing the original URL from which the request is initiated on the client. This request reaches the API gateway, which points to the AWS Lambda POST API, where the new short URL is created and stored in the database. The response is the newly created short URL.

Navigate to URL:

User initiates the request through the client, going through the API Gateway, it points to the AWS Lambda GET API that retrieves the original url from the cache, if the url doesn't exists on cache, then is retrieved from the database directly.

The response is the original URL, with a status 301 to utilize the redirect feature.

Detailed component design

Database:

Dynamo is a nosql database that can handle large loads of requests and data.

Create short url API:

The create API is the most interesting of both APIs, this generates a short url, using base64 the original url is shorten and stored in the Database.

Get url:

This API retrieves the original url from cache, if the url doesn't exists on the cache then is retrieved directly from the database.

Trade offs/Tech choices

Scalability with serverless can be easy and reduce the infrastructure to maintain.

Redis help us to retrieve the data faster and reduce the load of reads on the database.

The API are separated to handle the scalability separate, having different loads on each one.

Failure scenarios/bottlenecks

One of the potential future bottlenecks can be the reusability and uniqueness of the urls, at the moment they are permanent but the number short url are limited, future improvements can be to add expiry dates to shor urls.

Future improvements

Improve the scalability of the application on know peak times.