Loading...
able to redirect shortened url to longer/original url, able to shorten the url successfully, store the values, able to read from database and map the shortened value to original, handle the huge traffic for read and writes of urls
able to make system resilient to huge read and write traffic, make it consistent in data handling, access the most frequently used url in more scaleable matter, make sure the system is fault tolerent, design is scalable, design is performance efficient,
we accept 2048 characters and expected users at peak traffic is around 10000 users meaning each user will submit 2048 characters max, we can round it up to 2 mb for each user and 10000 resulting in 20000 mb, meaning 20gb of write request during peak time and 600gb over a month but also 0.33 gb of write per second. Wwe have 10000 users in peak hours and each user accesses the url twice per session therefore we have 20000 reads per session. if one url is 2mb of size, then we need to calculate is as 4mb since we request twice per user and 10000 users,it comes down to 40 gb of read per session. it is the double the size of writes. it is estimated that we have 100000 url shortenings a day and 20000 redirects therefore our design should be able to handle 200 gb of write and 40gb of read a day.
shorteningApi, redirectAPI i think two apis are enough the we can build more services around these apis to make it resilient and scalable. When we think of it this way, we assume that user does not request to update the shortened url or make any updates, write operation occurs only once and if we consider authentication we can then have another auth api
since we have lots of write requests we can have sharding in database to have faster indexing when redirects occur, write is easy but then we can store them and make sure they can be easily accessable. we can use hash key to shard them. we can also have replication in the system but it might overload the traffic with too many update requests, therefore we can have eventual consistency throughout the replication system to slowly pass the data between.
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...
when user requests shortening url it calls the api then load balancer redirects the services between the databases and gets back to the services with the right data
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?