Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
Should I focus only on the functionality of creating a tinyURL and then redirecting to originalURL?
What should be the response if there is no matching URL found?
Is there a limit on number of tinyURLs that can be created by a user?
List non-functional requirements for the system...
How many users could be asking to create tinyURL?
How long should the tinyURL be active?
What should be the length of tinyURL?
what should be the response time for creating tinyURL?
Estimate the scale of the system you are going to design...
200 requests per second for shortening URLs and significantly more for redirection (up to 20,000 requests per second).
Number of requests total for shortening = 200 * 60 * 60 * 24 = 200 * 4000 * 20 = 4000 * 4000 = 16000000 = 16MB
Number of requests for redirection = 20,000 * 60 * 60 * 24
Data associated with URL -
Short URL - 8 bytes
Original URL - 100bytes
Created time - 8 bytes
UserId - 20bytes
Expiration time - 8 bytes
Total capacity for one URL - 144bytes
Total storage needed = 144 * 16MB = 3200MB = 3.2GB
Database should be able to store 3.2GB of data per day
Total Data stored in a year = 3.2GB * 365 = 900 GB
less than 10 ms for the redirection request
creation process under 10 seconds.
Define what APIs are expected from the system...
HTTP POST - /shorten
String shortenURL(Strong longURL)
Response - 200
Response - 400 - not correct input
HTTP GET - /redirect
String redirect(String shortURL) - redirect
response - 302 - for redirect
response - 404 - not found
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...
Database design -
resourceId
shortURL
longURL
creationTime
userId
expirationTime
Index On - shortURL and longURL
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...
There will be a load Balancer that will distribute the traffic across multiple instances of service.
I would also use auto scaling for the services so that it can handle if the load increases more.
Caching will be implemented using Redis. When a GET request is invoked it will check if the corresponding longURL exists in Cache. If yes, it will return it. If no it will lookup DB and cache the value in Redis as well as return the user to redirect. The cahcing will have TTL of 1 day. Every time the user gets the info from cache the expiry time will be incremented by 1 day, otehrwise cache will be evicted.
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?