Requirements

Functional Requirements:

• User should be able to generate shortened urls from original url
• User should be able to change redirect url
• Users clicking on short url should get redirected to the original url
• Only admin user should be able to modify redirect url

Non-Functional Requirements:

• system should be highly available and eventually consistent
• system should be partition tolerant
• system should be low latency
• system should be highly durable
• system should prevent unauthorized modifications to settings

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

post /v1/shortenUrl

body:{

'url': 'example.com'

}

bearerToken: {

'userId': {uuid},

'scope': 'adminScope',

}

get /v1/getRedirectUrl/{uniqueCode}

# post /v1/refreshCache/{shortUrl}

# post /v1/refreshCache

post /v1/invalidateCache/{shortUrl}

High-Level Design

Client hits the shortened url, goes through api gateway, gateway directs flow to fetchOriginalUrl service, service fetches original url from cache, and directly from postgresql database if not present in cache.

Client calls post request to shorten url, goes through api gateway, gateway directs flow to createOriginalUrl service, service generates shortened url, repository layer calls the database to store the shortened url and original url. Unique urls are created by hashing the original endpoint.

But hashing won't let new redirect urls to have the same shortened url

Database Design

We will use a simple noSql database to store shortUrl and redirectUrl along with admin userId so that we know who is allowed to modify entry

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.