Loading...
1.system should be able to generate mapping of short to long url.
1.scalable.
2.highly available.
3.consistent.
POST /create-url
body: bigg url.
res: short url
POST /get-url
body:short url
res: big url
mongodb will be used without any sharding or partitioning
loadbalancer,
application server with auto scaling groups.
mongodb instance with redis cache.
a seperate service which will be having a global counter:
this service will have range of counter defineed for different applicsation server.
so each request coming to a. particular application server will be assigned a counter value from it's range and this counter value will be hashed to map short url which is then stored in db
1.web browser to loadbalancer.
2.loadbalancer to one of the application server which is attached to scaling groups.
3.application server to counter service and counter service to databse.
4.in case of reads, request will directly go to database and get the mapped url.
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...
Explain any trade offs you have made and why you made certain tech choices...
In case an application server fails, the counter service will block it's range. and when a new server comes up, it will be assigned the same range.
we can use queue for asynchronous processing between database and application server
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?