Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
given long url make short url
given short url redirect to long url
List non-functional requirements for the system...
low latency high availability
shorten tiny urls to longer urls for 1 million active users 5 urls per day
scaling based on peak usage times
Estimate the scale of the system you are going to design...
365 million urls per year
if we use all cap letters and lower letters and numbers it gives us 62 characters to use. if we use 6 characters for our shortened url we will have around 56 billion urls available which is probably enough for our use case
Define what APIs are expected from the system...
we need an api that takes in a url and returns the shortened url
POST: /create-url
params: long-url
status code: 201 created
GET: /{short-url}
status 301: redirect
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...
we will need a database to store short urls and long urls
we could use a nosql database:
{
shorturl:
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...
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...
Post:
GET:
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...
generating a url requires checking the db if it exists, prevents needing to block off sections of urls per machine to prevent collisions
Try to discuss as many failure scenarios/bottlenecks as possible.
for a simple url shortener we can handle duplicate submissions by just creating a new url.
we can also expire old urls using a set time by having a background job that runs every so often to delete old urls, or invalidating them so that they do not redirect to an unexpected url.
If we need more than 6 characters in our shortened url we can always expand to 7 to increase the amount of available short urls.
we can have users create accounts and that could change the expiration time and retrieve old shortened urls.
we are using a nosql server because of its speediness with the small amount of data we are storing.
if the user submits an invalid url, we can return a 500
if the user requests a url that does not exist, we can return a 404
servers will need to be able to scale horizontally.
we can use this using auto scaling groups
we could shard the db to allow it to also scale horizontally.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
Analytics:
counts for each url to determine what to cache
store ip address to determine where to locate caches
Rate limiting:
prevent ddos attacks.
Security:
prevent predicting urls