System requirements

Functional:

• Users should be able to create a tinyURL where service should generate an alias
• Service should redirect users to original url when prompted
• Users should be able to delete tinyURL
• Urls should be deleted after a given expiration time

Non-Functional:

• Highly available
• Should be minimal latency when loading url

Capacity estimation

• 100M Daily active users
• ~100M writes per day -> ~ 1000 writes per sec
• 100:1 read:write ratio
• ~100K reads per sec
• this will be a ready heavy application

API design

POST /shortenedURL

parameters:

userId,

originalURL

GET /shortenedURL

parameters:

shortenedURL

DELETE /shortenedURL

parameters:

requestingUserId,

shortenedURL

Database design

User:

userId

password

email

URL:

creatorId

shortenedUrl

originalUrl

timestamp

High-level design

1. We will need a load balancer in front of our api
2. we will have the url shortener service as a rest api
3. We will have a url deletion job that can run as a batch service and periodically query the database for expired urls and delete them from the cache and database
4. We can use a nosql database so that it can easily scale and the data does not require complex queries

Request flows

The request from the client will first hit the load balancer, then the load balancer will send the request to the url shortener service, then the service will send the url details to the database, then send a confirmation back to the client

Detailed component design

1. In order to ensure this service is highly available, we can setup a primary-replicas database architecture in order to distribute the read load and prevent a single point of failure
2. In order to ensure this service has low latency, we can add a cache in front of the database which the service will call. This can be a write through cache where when a new url is added, it will first add to the cache then to the database. This will ensure that the service will always have the latest data. We can follow an "least recently used" cache eviction policy so that any urls which are no longer being used can eventually be evicted. We can also partition the database by range of shortened url IDs it order to distribute the load.

Trade offs/Tech choices

1. Choosing a write through cache can impact write performance, but since this system is read heavy and urls should be consistent, this should be okay

Failure scenarios/bottlenecks

1. There may be an issue with the batch process as this may put pressure on the cache/database, probably it will need to delete in small increments or only during off hours

Future improvements

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