Loading...
User is going to provide the long-url or original URL. (optional: for the user to choose some section of the URL)
User is going to receive a shortened URL.
When the shortened URL is used - this needs to redirect to the originally given long-url.
Performance:
Initial creation - it's okay if there is some latency
We need high uptime and availability when the shortened URLs are used by some user
Availability:
Theoretically - short-URLs are only available for X number of days or months before they expire
Shortened URLs are shared, so this needs to be available to anyone anywhere
Security:
Probably want to rate limit the number of URLs a user can create (in the future there may be some sort of payment option to increase this)
Authentication - this can easily be done for initial creation, but is challenging for when the URLs are shared. To counter-act that - we need some wait to throttle calls from users/IP addresses
Data types: text / URLs - key/value pairs
this data is mutable - theoretically we can have multiple keys for the same value (counteracted with API creation) (this is only needed if users want to create custom short-URLs)
Access Patterns: given some key, give me some value
Scale:
Latency: fine to have some when creating the short URL, don't have to have any when rerouting user that uses the URL
Consistency: data = immutable, which makes this a lot easier. Never going to be an instance where a transaction of reading needs to await a writing transaction
Availability: high in every case
Users: SQL database
Data Storage: NoSQL database for key-value pair tiny URLs
Service: creating tiny-URL
Caching: limit the size, LRU cache
Loading Balancing: only for needed for partitioning database / caching
Backup: some redirect that ALWAYS works, if the key-value comparison doesn't bring you to original long-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...
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...
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?