Loading...
return a url that is shorter than the original one
consistency: each url should have unique shorten url and vice versa
availability: the service should be available all the time
scalability: the service should be able to handle the increase of service request
Estimate the scale of the system you are going to design...
DAU 1M per day
each user 5 web generation, read 20 time
write 5M per day
read 20M millions per day
storage 1k per url
5G per day
Define what APIs are expected from the system...
shoreten(given_url):
return shorten_url
get(shorten_url):
return original_url
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
hash_id: unique id for each url
shorten_url:
original_url
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design...
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...
flowchart TD
B[client] -->|shorten_url| C[load_balancer]
B -->|get original_url| C
C--> D{server}
D -->|look up| E[Database]
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?