System requirements

Functional:

1. create short url for big url
2. given short url, redirect to big url
3. delete short url from database
4. analytics(optional)

Non-Functional:

Scalable: highly scalable; horizontal scaling

Consistency: eventually consistent (its okay to provide stale data, but not okay to return nothing or fail)

Availability: high

Partition tolerance: high

faster read than writes: its okay to take time to add entry, but short to long retrival has to be faster(better for UX)

Capacity estimation

100K requests in a day:

in a sec 100000/24*60*60 ~ 2 req/sec

say a entry is like 4KB,

total storage for 10years is

4KB *100000* 365*10 = 1.46TB

data is relatively less;

this can be done on SQL database(less data, easy to manage, no need for distributed systems)

API design

1. public String encode(String bigUrl) -> short url
2. public String decode(String shortUrl) -> big url
3. public void delete(String bigUrl) -> void

Database design

URL table columns (uniqueId, bigUrl, shortUrl)

indexed on bugUrl for faster search

High-level design

user -> API gateway ->(encode service, decode service, delete service) each horizontally scaled with individual load balancer -> decode service is cached with redis -> else all three services hit DB -> SQL(PostgresSQL)

Request flows

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

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?