System requirements

Functional:

• Allows users to shorten URLS
• Redirect user to original URL

Non-Functional:

• Should always available
• Hash should be unpredictable
• Concurrently handle 10000 requests at a time

Capacity estimation

• Handle 10000 requests
• Database
• Shortened URL (VARCHAR) -> Max length 25 -> 25 bytes
• Original URL (VARCHAR) -> Max length 2000 -> 2000 bytes

API design

External Endpoints:

• /convert -> POST
• Convert original URL to short URL
• /redirect -> GET
• Direct user to original URL

Database design

URL conversion table:

• ORIGNAL_URL (VARCHAR, PK)
• SHORT_URL (VARCHAR)

High-level design

Shard databases by root domain alphabetically

Client -> Loadbalancer -> Server

• Redirect -> Check cache -> cache miss -> check replica DB
• Convert -> Check cache -> cache miss -> update primary DB

Client POST:

• Request goes through loadbalancer
• Send request to server

Client GET:

• Request goes through loadbalancer
• Send request to server

Request flows

Client -> Loadbalancer -> Server

• Redirect -> Check cache -> cache miss -> check replica DB
• Convert -> Check cache -> cache miss -> update primary DB

Detailed component design

Use Redis cache to cache shortened URLs

Serverside logic when writing to DB will first check if existing in cache, if not then update DB and update cache

Trade offs/Tech choices

NoSQL for database because Orignal_URL:shortened_URL will pretty much just be a key value pair

Failure scenarios/bottlenecks

Bottleneck:

• Too many redirects at the same time, this is why we use repilicas
• If primary DB is down, promote a synchronous replica as primary

Failure to convert:

• Need to retry

Future improvements

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