Loading...
Calculated for the next 10 years.
100,000 URLs created per day.
10 * 365 = 3,650 days * 100,000 = 365,000,000 URLs to store.
Origin URL: 100 bytes
Shortened URL: 10 bytes
Creation Date: 10 bytes
365,000,000 * 120 = 44GB/10 years.
We can start with around 100 GB of storage.
For the network:
1.1 URLs created per second. Create load balancers to handle these requests as well.
POST shortenURL(originURL) --> returns shortenedURL
GET originURL(shortenedURL) --> returns originURL
RDBMS such as MySQL to store a url_mapping table:
id
originURL
shortenURL
created_date
We can have a master/slave architecture for database replication. The web servers can write to the master DB upon a shortenURL API call.
We can also have a cache that holds commonly requested URLs.
We can potentially have a shortened URL creation service that creates an unpredictable shortened URL by:
SHA256(creation_time + originURL + salt). Salt can be the identifier of the SQL row.
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...
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?