Loading...
The system should take a long url and produce a shorter one. The url should be a maximum of 16 characters and should redirect the user to the original page.
Should store the urls for 5 years
1000 urls an hour or about 17 a minute.
post v1/shorten with a body of {url: longUrl}
get /[shortUrl] which redirects you to the longUrl
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...
Should have a rate limiter and load balancer that goes to the web servers. Web servers should scale and point to the database with the shortened url. Webservers should uniquely hash the url and store it in a database
client makes request -> request goes through rate limiter and load balancer to the webserver webserver goes to the hashing service and the response gets stored in a database. the response gets returned to the caller
rate limiter prevents any user from ddosing the service. Load balancer allows the requests to be distributed to different web servers.
load balancer is only really required when you're getting slammed. It adds complexity that may not be required
if hashing fails, its going to prevent the flow. You may also want your databases to be sharded so if one fails, you have a backup
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?