Functional:

1. Generate short URLs from long URLs.
2. Redirect to long URL from the short URL.

Non-Functional:

1. Redirect to original URL from short URL with low latency.

Capacity estimation

Traffic Assumption:

1. 200 RPS for creating short URL.
2. 20000 RPS for redirecting short URLs to long URLs.

Storage:

1. LongURL(100 bytes)
2. shortURL(10 bytes)
3. createdAt(10 bytes)
4. createdBy (20 bytes)
5. expirationTime(10 bytes)

Total: 150 bytes => roundoff to 200 bytes

Daily Storage => 200×60×60×24×200 => 3.4 GB/day

1 year storage => 3.4 * 365 => 1.241 TB =>roundoff 2 TB

API design

1. createShortURL(): This API will take in the long URLs and create short URLs and save it to database.
2. redirectToOrginalUrl(): This API will take in the short URL and redirect the user to the original URL.

Database design

We can use Dynamo Db to store the mappings, since the system is read heavy and requires strong consistency.

DynamoDB provides horizontal scalability, high performance, and optional strong consistency.

High-level design

Request flows

Write Path:

1. User submits request to create short URL for a longURL.
2. The mapping is created and saved to database.
3. Then the mapping is saved to cache.
4. respond to user with success code 200 and and the shortURL.

Read Path:

1. User clicks on short URL.
2. The mapping for short URL is checked in cache, if present respond with status code 302 and redirect user to original url.
3. Else, fetch the mapping from database and respond with status code 302 and redirect user to original url.

Detailed component design

API gateway: This allows us to streamline user requests to different API, acting as a bridge between client and different background services.

We can allow rate limiting, which in turn, can limit the number of requests made to the application and save the application from DDoS attacks.

Cache: Caching with tools like Redis can reduce the overload on the servers, by caching the mappings and directly responding to client. This results in low latency and high scalability of the application.

Trade offs/Tech choices

DynamoDB: This offers heavy read operations, which is necessary for this application and offers strong consistency, since the shortURL should be readily available to the user.

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?