System requirements

Functional:

1. Create Short URL: Given a long URL, the service should generate a unique short URL.
2. Redirect to Long URL: When the short URL is accessed, it should redirect to the original long URL.

Non-Functional:

1. Scalability: The service should handle a peak of at least 1 million requests per day.
2. Availability: The service should be highly available and resilient to failures.
3. Response Time: Redirection requests should be handled in less than 10 milliseconds, while creating short URLs can take longer (say, up to 1 second).
4. Increment of users should only need database to be horizontally scaled.

1. Suppose there is 1 billion of shortURL - longURL mapping. We will calculate the storage needed. 1 short URL has 10 byte and longURL has 90 byte which make total 100 byte. Then we will need 1billion & 100 byte = 100 billion byte, which approximately 100GB

API design

POST /v1/shortURL

body : {

longURL : string

}

resp : {

shortURL : string

}

GET /v1/longURL?shortURL=string

Database design

key value pair database will be a good choice here, because we will need to access longURL based on shortURL. It also ensure idempotency.

example

tinyurl.com/LX1GC : www.linkedin.com/profile/DariusChandra

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Request flows

1. user put longURL at the frontend page,
2. user press create shortURL button
3. frontend page call POST /v1/shortURL API. Then get the shortURL as response
4. user type the shortURL into the browser
5. shortURL will be redirected to longURL. Behind the scene of redirect mechanism, it called the GET /v1/longURL?shortURL=string API

Detailed component design

KV database should be a NoSQL database that can be horizontally scaled. The API server can be an ECS instances that autoscale if there is huge traffic

Trade offs/Tech choices

We choose KV database NoSQL such as DynamoDB because of the access pattern where we map shortURL to longURL. It is managed by AWS for the scaling.

Failure scenarios/bottlenecks

• DynamoDB is down because of high traffic due to read.

Future improvements

• add caching mechanism, since some shortURL will be frequently visited. We can use redis or memcache.