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 (<200ms)
• high availability
• scalability (to support lots of users and redirects)

API Design

//Create urls

POST /urls -> 201 - url

body {

alias,

url,

expirationDate

}

//redirect

GET urls/{sort_url} -> 302 - Original url

High-Level Design

The client requests to a apigatway, api gateway routes the request for the right service. If it is a creation request, the shorter-service receive the necessary parameters to create a new short-url and then persists it on DB, the service returns 201 as response.

For other side, if url-getter-service is demanded, this will looking for the short url in the cache by sort-url, once data is found, 302 is returned as response

Detailed Component Design

To ensure that the system is highly availailable and scalable, we are using a loadbalancer, so requests may be routed among the instances of a service. Its gonna help with spikes, most in getting rediction. Another tool that is designed to help us with. Once apigateway receives a request, it directs the request to loadbalance, and then loadbalancer will route the request to the most availables instance.

Loadbalancer also help us to keep low latency working with caching strategy. We put a cache between url-getter-service and the DB. This cache is key-value db that is modeled to keep short-url - original-url info, this is gonna respond much faster to get url operations. In order to keep the cache updated, everytime the get-service does not finds a data in the cache, its gonna look for it in the postegres db, once it is found, the service is gonna persists in cache as well. Cache has TTL policy that matches the expiration date defined in the url creation.