System requirements
Functional:
Shortening a URL that is unique
Non-Functional:
highly available, bandwidth, size, scale
Capacity estimation
each character is around 2Byte, the URL should be something like www.example.com/SOMETHING. the size of "SOMETHING" can be around 7 chars[0-9Aa-Zz], including numbers so in general 10*52*7=3640 options.
API design
user request to server:l
{
http: POST
body: {
userId: int
url: string
}
}
server to zookeeper:
{
http: POST
body: {
userID:int
url:string
keyId: int
}
}
zookeeper to DB:
{
http:POST
body:{
userID:int
url: string
shortURL:string
}
}
Database design
here the read and write can be fast and in a huge size, relationship doesn't seem to be an important feature here between links so there is no point of using relational DB. Instead we can benefit from No-SQL for fast read and write. also no sql is unstructure so we don;t need to be necessarily worried about it
High-level design
user send a request with a URL that wants to be shortened. the request should go through a load balancer in case there are many request coming. then from LB the request goes to a server such as zookeeper to make sure that the request is going to be unique and no collision happens. then the result would be saved in a NO-SQl database and at the end we send the response to the user. We can have a cache here as well to cache some of the famous URLs or etc
Request flows
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...
Detailed component design
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...
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?