Loading...
-generate a short link
-redirect the user to the original link by the short link
-handles about 50 calls each second
-saves millions of links
-short link are unique
-high availability for clients that want to access their links
-low latency when creating new links
If each row of data that consists of the short url and the long url is 100kb then we need about 500gb to store it so about 1 tera byte .
we can use a key value data base like dynamodb because it has very fast read operations and we need that for fast redirection.
We also won't need to store complex data structures and use joins.
In the future if we need to save more complex data we can add another db.
We also have a redis db, which we can use for 2 purposes:
We need to use a load balancer to handle a large amount of calls everyday.
We will add a gateway service that is in charge of forwarding the user to the relevant micro service, so if one is down the other functionality is not affected.
We will have a url generation service that gives the user a short link from the redis and saves the original url in the dynamo db. It will also fill out the redis with new links periodically.
Another service is going to be the url redirection service, which will return the original url when given the short one. it will get it from the redis cache or from the dynamo if it doesn't exist there.
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
-we can also periodically go over the database by creation date and delete expired links that are no relevant anymore and reuse the links for new ones.
-Both service can be scaled horizontally to handle more requests.
we can also put them in different geographical areas to make the speed and the availability better.
-dynamo db being a key value data base can have fast reads and writes and also scale and hold a lot of data.
-seperating the url generations and redirection can prevent down time for one feature if the other one is down.
-redis is a good cache service for faster access by using ram memory
-the prepared short urls can run out of urls if there are a lot of reuqests suddenly. so in that case we need to have a fallback of manually creating links which might be slower then taking it from the redis.
-there might be a possibility that the random generation will create an existing url. we need to check it doesn't exist in the db already before we give it out.
-we might run out of urls, then we can see if we can make the url longer or delete expired links
we can add a data base and service for statistics if the user wants to know how many times the link was accessed. we can also do a payment feature that saves the links from expiring as long as the user pays, and save the metadata for it in a relational db.