Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.

Non-Functional Requirements:

• Low latency on retrieval
• Scalability of solution
• High availability (replication)

API Design

Url creation path:

• Client sends HTTP POST request to "admin.domain/api/urls"
• Request contains JSON with at least url parameter. There also could be store some time-to-live parameter in the future.
• As a response there could be returned JSON with "shortened-url" parameter.

Url retrieval path:

• Client sends HTTP GET request to shrt.domain/<hash> The response should return 404 if hash is invalid (nonexisting/deactivated) or 302 with Location header containing original URL

High-Level Design

There are two separated servers:

1. The "administration" service to administrate - creating and deleting.
2. The "retrieval" service to access shortend urls.

Both services access the database, that contains entries with shortend and original urls. The database.

Detailed Component Design

Firstly, we access the CDN to reach our administration frontend.

When we create a shortened url, the Frontend reaches first Api-gateway. This api-gateway handles authentication, authorization and rate-limiting. After successful verification of requiest it is routed to Administration service.

The Administration service is stateless, so it can be scaled. Firstly it needs to get new identifier from Hash Generator.

The hash generator generates random UUIDs and makes sure, that they were not previously used.

After hash is generated, the original url is stored in read-write DB (may be relational Database).

Using Change-Data-Capture, the entry is propagated to Read Database. This Database must be replicable and must use shards. Target shard is selected using consistent hashing basing on shortened-url.

Coming back to url creation - after persisting an entry in Read-write DB, we need to make sure, that the result will be available for client, so we need to access Retrieval service to verify it. We can use short pooling for reaching Retrieval service with retry in case of failure.

After confirming the result is available, we can respond with the result (shortened url) to client.

URL retrieval:

When user request shortened url, request is routed to LoadBalancer which executes rate-limitting to avoid flooding our service. LoadBalancer firstly checks if searched value is in cache - if not LoadBalacer routes request to one of multiple RetrievalService. The RetrievalService using consistent hashing queries one of database shards to obtain the result.