System requirements

Functional:

Given a long URL, return a short URL

Given a short URL, redirect to Full URL

Max input url length: 2000

Max concurrent req: 50K

Url expiry: 1 Year

Occasionally clean sead Urls

LifeSpan : 10 Years

Non-Functional:

System shall be scalable.

shall be always available.

Capacity estimation

Each url -> short_url map would need 2000 + 100 + Creation_Date = 3KB.

Number of unique: 1 Billion

Total space req = 3 TB

API design

post urls body:long_url

get urls/short_url

delete urls/short_url

post urls/expire

Database design

shortUrl ; longUrl ; CreationDate

Index on short_url and long_url

Unique constraint on short_url and long_url

High-level design

total available chars:

26 smallcase alphabets

+ 26 caps alphabets

+ 10 numerbers

+ 2 special chars = 64

Hashing -> sha256 -> 256 B =

32 Bytes

Base64 encoding: 256 / 6 = 44 chars

Request flows

client -> LB -> service instance -> cache -> DB

Detailed component design

2 Key value pairs are kept in cache 1. short -> long, 2. long - > short

Highly available multinode DB like cassandra is used to avoid single point of failure.

Redis is used as caching system

Concurrency Requests for same long_url ?

Redic cache be used for Distributed locks against a long_url

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

multinode LB -> always available

multiple service instance -> always available.

multi-node db -> always available.

multi-node cache -> always available

Future improvements

When auto-expiration shall be triggerred?

Can short_url be made shorter?

Scale for 100 years of data.

Analytics support to calculate popularity vs bucket_of_people