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 to redirect from shortened to actual URL
• High availability so shortened URLs always resolve to the original one
• Horizontal scaling when there are spikes

API Design

POST /shorten: Using the original URL generates a base62 hash version and stores it in both the cache and the database (write-through pattern)

GET /url: From the shortened version (parameter) obtains the original URL

High-Level Design

There is a load balancer in front of the API servers to control spikes in its usage. These servers are stateless and auto-scale depending on the usage of the platform.

For POST, the servers take the URL, hash it using base62 and store the shortened URL in the cache and the database. It is important to mention that the storage happens using the hash as key so the GET endpoints works seamlessly.

For GET, the shortened URL is used as a key to retrieve the whole URL from the cache.

Detailed Component Design

The distributed cache uses an LRU eviction so we keep the most targeted URLs. TTL does not apply well here since it might conveniente to keep records in cache that are obtained constantly. What makes sense is to limit the size of the cache.

We expect a high level of cache hits since we use write-through, but the model can scale by adding more replicas in the SQL topology.

When there is a miss, the URL is obtained from the SQL database and updates the cache.

There is no collision because base62 guarantees that (ID is unique).