Loading...
Should receive URLs and return a transformed, shortened URL, storing the original in a database
Receive user traffic via a shortened URL and redirect the user to the proper corresponding URL.
Should be fast and available, with re-directs taking very little time
Must be consistent, the same tiny URL should not go to more than one web-page.
Should be able to handle a large amount of user traffic at once
Estimate the scale of the system you are going to design...
Large scale, users from all over the world, millions of requests a Day
postURL() - send a url to the server to be stored, return the altered URL.
getRealURL() - request an actual URL, sending the corresponding shortened one
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...
Use a SQL database, storing the original and shortened URLs in Rows. If we want to allow for a many-to-one relationship between tiny URLS and Real Urls, we can normalize by putting real URLS in their own table.
If URLS have requests built into them, can store Request data in a JSON document within a column
Since we want the system to be available and consistent, should replicate our database with a single-leader method of consensus, making reads quick. Do asynchronous updates to follower databases to avoid the leader from being overwhelmed.
Store URL parameters in the JSON since we don't need SQL features (wont index over them, nor join them)
Tiny URL ID | tinyURL | foreign key to real URL
real URL ID | real url base | JSON containing parameters
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?