Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
User can create URL
User can retrieve URL
User can Delete URL
User can create a custom URL
List non-functional requirements for the system...
System should be scalable if we are talking about tons of users
System should be always available so that rerouting will work
System should be durable
Estimate the scale of the system you are going to design...
Urls: 1 billion possibly
Users: 20 million that create URLS
Define what APIs are expected from the system...
The Api should consist of
Post /postUrl (string url)
if a user wants to create a new url we will retrieve the url from the client and return a new tiny url.
Delete /deleteUrl (String tinyUrl)
If a user wants to delete their tinyUrl we should be able to delete it based on the tinyUrl that they send us.
Get /getUrl (String url)
A user should be able to get the url that they have previously created
Update /updateUrlCustom (String url, String newUrl)
If a user would like to update a url they should be able to put in the url and then the newUrl that they want
Update /updateUrl (String url)
This will update the Url for them with a new set of things
Post /postCustomUrl(String url, String customUrl)
This will create a url that they can customly make.
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...
Table URL
Id
OriginalUrl
TinyUrl unique
UserId FK Can be null
Table User
UserId
Name
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...
The high level design will have the client which will have a load balancer in between in order to do operations based on many horizontally scaled apis. Th load balancer will get a request from the client and in a round robin fashion so that no server is too overloaded send the request to an API. The apis will be serverless so that we can horizontally scale them easily. The server will retrive data from a database in order which will contain all of the relevant information. Which the server will then send back to the client. The DB will be a NOSql DB so that we can have Consistency and Partitioning like a MongoDB. We can horizontally scale MongoDB efficiently and even though SQL is more structured for this case we will need to use MongoDB to handle the amount of queries to the DB. Also it will make sure that when the db may go down for a second another one can take its place. And users need consistent data. Also we will make sure that the field is Unique by making the field in the db unique. For read heavy we will also add a caching layer in front of the DB so the tiny urls that are constantly used can access the cache rather then straining the DB.
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...
The client will create a url which the load balancer will send to one of the servers. The server will pick up this url and the server will create a new url based on not sure what. Then it will add it to the DB. If there is a user with a custom url they can add it as well we just need to check in the db that the custom url is ok to use. If it is ok then we create a url and send a 200 if not we say you can't use it and send a 404.
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?