Loading...
```
GET http://bit.ly/{suffix}
``` ^^ get generated link
```
POST http://bit.ly/generate
{
"original_link": "{...}"
}
```
it seems, we just need map generated links with orignal one and vise-versa (to exclude duplicates)
so at first we can got with a single table like:
`orignal_link | generated_link`
and create 2 indexes , one for original_link, and second for generated_link
for the start, we start with api-gateway, as an entrance point (to handle auth, rate-limit and routing things)
gateway will forward request to the shortener service, shortener service will request the url from database and redirect request to the found url.
for now there is no any scalability momements, but we will describe them in deep-dive secrtion
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...
to make the system scalable and highly available, we need to consider the write and read pattern load here.
mostlikely the reads will be happen much often then write
so for reading we need to add cache, preferably to keep most popular content (LRU?)
we need to make db shardable as well, to be able scale it due to large amount of traffic. to do so we need to choose a good shardable key, let's choose by hash of the original url.
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?