Loading...
The system should take a long url and produce a shorter one. The url should be a maximum of 64 characters and should redirect the user to the original page. The hashing mechanism should create unique hash something like snowflake algorithm.
Should store the urls for 5 years. There should be collision resolution.
We have 25000 employees. On average they generate 1 document a month. Thats 833 a day or 34 an hour we can then safely round up and say they'll be making 1 url a minute
post v1/shorten with a body of {url: longUrl}
get /[shortUrl] which redirects you to the longUrl
Database should be a noSQL, key/val database with the key being the hashedvalue and the val being the longURL. This will help with collision resolution since we'll know if a hashed value exists and we can resolve it.
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?