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:

• List the key non-functional requirements (e.g. low latency, scalability, reliability, etc.)…
• creation of shortened URL
• redirection service of existing URLs
• low latency, cached responses
• load balancer
• 1 month life in cache
• redirection service
• rate limiter

API Design

# Save New Short URL

POST /api/saveUrl {

requestedURL:

}

# Request Short URL

GET /api/getShortURL {

shortURL:

}

High-Level Design

• A single API with two endpoints: one for storing the new URL, short URL combination. The other will handle the redirect.
• Prefer availability over consistency.
• We expect 100 requests per second.
• We take advantage of rate limiting for security and performance.
• If under limit, we use a load balancer to divide up traffic.
• Once we reach the URL_Shorten_Service, we first look for the requested URL in cache. If we find it, the Redirect_Service will send a redirect to the stored, longer URL.
• URL_Shortening_Service will send a message to Message Queue for logging.
• If we process a GET that has no URL in cache, then check the database. If in database and not in cache, do the redirect and save it in cache. If not found in either, we show a website with Not Found.
• Prefer long caching.
• If we receive a POST request, then we use ID_Generation_Serivce to store in cache and the database.
• The database will store in cache and database for maximum of a year.

Detailed Component Design

• The rate limiter will keep repeat requests under a threshold from similar IPs.
• In order to achieve stateless architecture, the rate limiter will write an id from the source and provide a 429 if over the set limit.
• The load balancer will use round robin to allow basic horizontal scaling.