System requirements

Functional:

1. Creation of Short URL: The service must be able to take a long URL and generate an associated short URL.
2. Redirection: Given a short URL, the service should be able to redirect the request to the associated long URL.

Non-Functional:

1. Availability: The service must be highly available, especially for redirection functionality.
2. Response Time:
   • Redirection should have a low response time, ideally less than 10 milliseconds.
   • Creating a short URL can take more time but should be less than 10 seconds.
3. Scalability: The storage should be highly scalable to accommodate the increasing number of requests for creating short URLs.

Capacity estimation

• Creating Short URLs:
  • Around 200 requests per second.
  • This translates to approximately 12,000 requests per minute.
• Redirection (using Short URLs):
  • Around 20,000 requests per second.
  • This translates to approximately 1,200,000 requests per minute.

API design

[POST] /create

• body: URL (original URL)
• Uses UUID
• Adds the URL into the database
• Returns a shortened URL

[GET] /[id]

• Returns 404 if not found
• Redirects (203) to the original URL.

Database design

ShortenedURL:

• id: string (the shortened UUID)
• originalUrl: string (the original URL)

High-level design

Client -> API Gateway -> Cache or server -> DB

Request flows

For adding a new URL

1) User enters original URL via client

2) Client sends the original url to [POST] create

3) An ShortenedURL is generated.

4) The UI shows the shortened URL

For accessing a new URL

1) User enters the site via the client

2) The request goes to the API gateway and the cached is checked. If the cache is empty, check the database

3) If the database is empty, return a 404.

4) However, if its found in either cache or database, a 203 is returned and user is redirected to the original URL

Detailed component design

For the API gateway, there will be a cache used. Redis is ideal because it is in-memory database which is faster than RAM, its a key-value store.

A SQL database is used because there is unlikely any changes in the schema, and capturing single queries are faster with indexing.

Trade offs/Tech choices

SQL vs NoSQL

Redis vs Memcache

Failure scenarios/bottlenecks

A higher influx of users are way above the estimated number of users. As such, the server is overloaded.

Not only that, as there are too many records, it would be expensive for the database to scale.

Future improvements

For the high influx of users:

• Centralised to decentralised systems which support load balancing to distribute the workload
• Rate limiting to reduce the number of requests at a time

For the database:

• Sharding: breaking a database into smaller pieces
• Replication: a backup to ensure availability
• Horizontal scaling