Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
generate new link for every link
store mapping of shortened link to database
retrieve long url
user auth for admin functionality
link expiration
List non-functional requirements for the system...
scalability: requests of 20k / sec
availability: 99.99% uptime
response time: less than 10ms
security: user & mappings encrypted
extensibility: analytics, link customization
Estimate the scale of the system you are going to design...
small scale, 20k/sec could mean one link going viral.
Define what APIs are expected from the system...
generate link
save link
get link
edit link
create profile
get profile
sign in
sign out
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...
links database
url database
user database
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. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
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...
caching for frequently visited links
url fetching should be a separate process, assuming there may be more visits than link creation
api gateway, would let us know what part of the system would need to be optimized or separated into multiple processes, for better caching and processing of actions
user database and link database should be separted, for security and optimization, since users visiting links do not need info about the user who created the links
webpage for creating links should make it so users could create the url, and have it automatically expire in a quick way, so that it makes it an easier platform to use. but if they want a more persistent link, they could create an account so they could manage the url they've created
shortened url should support billions of urls, and also be easy to type out, so we need to use a combination of characters: a-z, A-Z, 0-9, so that it could create billions of links, without any collision happening frequently.
Explain any trade offs you have made and why you made certain tech choices...
do analytics portion after
requiring user profiles for creating links would prevent spam, but also could prevent platform usage
Try to discuss as many failure scenarios/bottlenecks as possible.
links could have multiple short urls, but one short url should only map to one long url
there should be a user profile created for creating new short urls, to prevent spam
don't need profile to visit short link, but could rate limit ip addresses / browser profiles to prevent users from ddos and malicuous activity
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
expired links should still have the url in the mapping, but just not retrieve the link
check mapping before creating shortcut
analytics should be linked to the short url, not the long link, for internal use, long links could be tracked - but the end user doesn't need to know that initially