Loading...
Takes in URLs and spits out smaller URLs. These smaller URLs should redirect to different sites.
Ensure a fast read time under 100ms for directing a shortened URL to a full one, I would pose that anything under 1000ms is acceptable for generating (writing) a shortened URL.
Mappings of shortened to non-shortened URLs should be somewhat secure but we can filter out full URLs via something like a bloom filter.
Could be a very large number of people using the service at any point in time, easily in the number of millions. We expect to handle more reads than writes. It wouldn't make sense that a tinyURL is generated with only one visit, it would make more sense to just use the full URL at that point.
JSON should be fine since we are really only sending plaintext anyways.
We will be using RESTful API
There should be a create endpoint which takes in a longURL and returns a shortURL and a get endpoint which takes a shortURL and redirects to a longURL.
The database will be a document store solution similar such as MongoDB, we use this over a simple key-value store as it may help store other information such as time to live so we can invalidate certain shortened URLs after a predetermined date.
We could use either a software or hardware load balancer, the software one will be cheaper and we can use one such as HAProxy which is open source. We shouldn't need to require a load balancer as we do not expect it to handle too much logic and as such does not need to be too powerful.
This load balancer will interacts with either the read API or the write API which interacts with the websevers which in turn also interacts with the persistence which is the databases.
There will also be a caching layer because there may be some very frequently visited tinyURLs during an influx of traffic (say I posted an advertisement during the superbowl using the tiny URL service).
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...
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...
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?