Loading...
1) Send a url and get a short link as a response.
2) The link handles redirects for 10 years after it's created.
1) The link creation should not take more than 1 second.
2) It's not nessesary for the link-website relation to be immidiate consistent. Eventual is fine (up to 1 minute).
3) Scalability: we should be able to have 1 billion links actively working.
4) Reliability: if any part of our solution goes down, all the links should continue working without any downtime.
Original webiste url:
max 200b
average 30b
The shorted link:
max 20b
1 billion pairs => 50GB we need for storage
100 writes per second.
10 million reads per second.
POST api/v1/create/
{
"original": ""
}
(update, delete are similar)
GET api/v1/get?{shortedUrl}
noSql DB with
{
"originalUrl": "",
"shortedUrl": ""
}
It scales better than SQL, and we are not interested in relations between items.
In-memory key-value DB having shortedUrl as a key and originalUrl as a value. Frequently used items will go to this DB from the main one and be there for some time (maybe 24 hours).
It makes sense as the links many times are used intensively right after creation and then are abandoned. (Conferences, classes, etc.)
A user calls the Create/Update/Delete service to create his short url. The service requests the uniqueness service for the next unique url, store it in noSQL DB and in-memory DB, and returns the answer to user.
When a user makes a request to a short version, the Redirect service serves the request, it looks up the short url first in in-memory DB, if not found - in main noSql db. And returns the redirect to the original website.
Let's discuss how we store data in noSQL DB. It makes sense to use a cluster of several instances. Since the shorted url is a random sequence of symbols, we can evenly distribute the data amongst DB instances. We can use a "circle" of instances.
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?