Loading...
For storing original url string, assume 1kB per URL, along with the metadata such as date posted and title.
About 10,000 users per day. Assuming more people are using it for reads, than writes.
Assume about 10% of people a day are shortening 5 links on average a day, 1000*5 uploads a day. 5000 * 1kB = 5MB a day for writing.
Estimating about a 10:1 read-write ratio that makes 50M reads per day.
Write API will be in charge of creating a unique shortened link, can use user's IP and timestamp to create a hash and will check if result is already in Write API, if it is, generate a new link and try again.
Read API will receive the shortened URL and provide the unshortened version.
For the database, it will store the metadata along with the unshortened link, whenever a request for the original link is made, will look in database by using shortened link as hash and return via the Read API.
The client sends a request to the serve, by uploading the link they want to shorten, it will go to the write api and generate+store the link via the write API. Reads are done in a similar fashion, except using the Read API instead.
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?