System requirements

Functional:

Expose API to get a url from client

Generate unique alias for the url

Store the alias and the original url in the db.

Redirect to original url when client clicks on the alias

Do we have a retention period - expiry date of urls - say 30 years

Non-Functional:

Should be scalable and extendable

The databse should be indexed properly to fetch original urls in efficient way

Capacity estimation

Suppose the system gets 1 million tinyUrl generate requests per day

And suppose we take read write ration of 100:1, so each url is accessed 100 times on average in a day - 100 million read requests.

Number of total requests = 100 million -- rounding off

number of request per second = 5000000/(24*60*60)

=rounding up to 120 rps

suppose for each record we need 5 kb space to store

so for 1 million - about 5 TB per day

Say we store the urls for 30 years

so total storage needed = rounding to 150 TB

API design

1. shortenUrl(String original Url, userId, expirationDate = None)
2. redirectUrl(String tinyUrl)

Database design

we need a simple mapping for shortUrl and original Url

we can use a key-value kind of mapping and store below data:

1. shortUrl
2. orignalUrl
3. userId
4. creationDateTime
5. expirationDate

High-level design

We have two microservices

1. ShorteningService
2. Repository Mapping Service

We could also include a messaging system to communicate between the services, shortening Service will publish to the queue after generating tinyUrl and the Mapping Service could poll from the queue.

Also we can include a cache. For redirect requests, the service should first look into our cache.

Request flows

The client sends reuqest through APIs

if it is a shortenUrl call, the request is sent to ShortenUrlService which will then apply a algo, create a unique tinyUrl and publish to queue.

This queue would be polled from a QueueService which when gets a new message, calls the Mapping Layer to persist in the db.

If it is a redirectUrl, we can directly call the Mapping Layer and return the original url, first check in cache and then in db.

Detailed component design

1. The tinyUrls generated should be unique, we can implement a hash algorithm. Also we will need to check if the hash is unique or not before persisting to db.
2. redirectUrl should be handled effectively to reduce latency. We can introduce CDN which will cache the data closer to the user.

Trade offs/Tech choices

1. preferred microservices architecture as the service requires scalability. Also the two API calls can be handled independently.
2. Key-value mapping - so chose NoSQL
3. We are also implementing a queue service, this could be Amazon SQS. This was we can seggregate the algorithm to generate a hash unique tinyUrl and the code to persist it into db without having to wait for the hashing to finish. - observer pattern

Failure scenarios/bottlenecks

1. If Mapping Service fails, it will directly implement the redirectUrl API and would be the cause of the Single point failure for our app. We need to implement this service very effeciently.
2. Cache fails - will increae the latency when trying to acess urls.

Future improvements

1. We can give option to support custom url.