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 in redirect
• horizontal scalability
• CAP, consistency for url shortener
• high availability for creating short-url

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

for creating short url:

POST /urls/?alias

{

long_url:

}

response:{

status: 200 ok

short_url:

}

for redirect using short url:

GET /urls

{

short_url:

}

response:{

status: 302 temporary

message: redirected to orginal url

}

here status: 302 temporary, this will ensure that caching will increase redirect speed, as db need not be queried every time

temporary storage will ensure querying db after cache is evicted, so that the logs during redirect using db , can be used for monitoring and analyti

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

components:

creator

consumer

url shortener service

redirect service

api-gateway for authentication, authorization, rate limiting and request routing

for secure connections, https protocols

load balancing algo: least connections

CDN for lower latency.

to ensure uniques identifiers i'll store a counter in a db (redis)centrally accessible to all servers for url-shortening service and hash it for security.

then keep incrementing a counter on new url request.(even if there is any failure , we'll have redis cluster with replicas for failover).

we'll do exponential retries, with a jitter added.

if there is any failure with one of the services, we'll use circuit breaker to avoid cascading failures

separate pool resources i.e. bulkhead pattern to avoid one service impacting another.

to avoid race condition i'll use locking on db

cache

db for long-url to short-url mapping and other details

for redirect service, we'll first check if long url for that short url is already prsent in CDN, if yes we return data from there and redirect to right place

otherwise, CDN pulls the data from orginal server, updates itself and then returns the requested url for redirect

if redirect fails we analyze the logs using analytics service and use it to improve the services

for caching we will use redis cache and cache details like short url to long url mapping, and if any alias is specified

in db we store details like user info, short url, long url, alias if provided.

in case all the short urls have been occupied, we will handle service unavailability gracefully by showing please retry after sometime

the ttl in db wil lbe used to clear out data once the ttl for that data is reached and there is space available for more new urls

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

to allow horizontal scaling, when there can be high reads or redirect requests, we have a load balancer

to reduce latency we will use read through caching for reads

for faster writes, we will do write through caching(eventual consistency)

we will use LRU cache eviction strategy

for monitoring and analytics, we will return response 302 for redirect instead of 301