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 - it's crucial so user do not waits long before redirection
• Horizontal scalability to handle increasing traffic on viral urls
• 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 paths:

1. The "administration" path to administrate - creating and deleting.
   1. The services are accessable via CDN, then frontend, and apigateway.
   2. The main component is Administration service that takes care of storing data and reaches Identifier Generator to retrieve hash for newly created entry.
   3. The Identifier Generator stores already generated IDs in Identifier database, so it can assure it's uniqueness.
2. The "retrieval" service to access shortend urls.
   1. The services are accessable via CDN, then frontend, and apigateway.
   2. Api gateway verifies if the result is present in cache - if yes it returns the cached result.
   3. If cache hit is missed, the Retrieval service that takes care of reaching entry for given shortened url.

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 Identifier 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).

Database assures that the identifiers are unique (e.g. by unique constraint in relational Database).

There is only one instance of Identifier 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. The rate-limiter should reject excessing coming requests.

LoadBalancer firstly checks if searched value is present 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.

The cache stores results during return to LoadBalancer. There should be a TTL policy.

The administration servlice could also disable shortened url. Then the information should remove entry from

cache and from read key-value store.