System requirements

Functional:

the user should be able to send a large url and receive a short url back.

the user should be redirected to the long url when they reach the short url

Non-Functional:

low latency when redirecting

availability > consistency

URLs need to be unique

Capacity estimation

API design

REST API format

Core Entities:

Long URL

Short URL

User

POST /url

Params: Long URL : string

custom URL: string (nullable)

Expiration time: datetime (nullable)

Return: short URL: string

GET /url

Return: redirection 301

Database design

URL:

id: int/guid

LongURL: string

ShortURL: string (INDEX)

CreatedBy: int (FK, to User table)

CreatedAt: timestamp

ExpiredAt: timestamp (nullable)

User:

id: int/guid

email: string

paswordHash: SHA-256

High-level design

Using cache for low latency retrieval for most frequently used short urls

Request flows

SO WHEN USER CREATES A NEW URL, IT GOES TO THE SERVER (AFTER GOING THROUGH THE LOAD BALANCER WEIGHTED ROUND ROBIN) it does a write to the db

Now for read, it checks in cache first, if it doesn't find it then it goes to server, then to load balancer, then to read dbs and add this in cache

In this case, I can use Redis cache with a ttl/ least frequented data and I can also cache on user's system in local storage or cookie

then the user is redirected to the long url

Detailed component design

Trade offs/Tech choices

eventual consistency

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?