Loading...
Receives full length URL and returns shortened URL.
List non-functional requirements for the system...
100,000 URLs per day
100,000 / 24 = 4,000 URLs per hour
4,000 / 3600 = About 1 URL a second
POST long URL -> returns short URL
GET short URL -> returns long URL
The database can be a key-value store mapping short URL to long URL
The client can POST or GET to application server.
Application server saves URL mapping to key-value store.
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...
The application server can be scaled either horizontally or vertically. Since we need to support 1 URL per second, a handful of instances should suffice (since transactions shouldn't stay open for more than a few seconds, one application server should be enough but we can have a couple more for redundancy in case it goes down).
The database can also be scaled, independently of the application, if necessary. If we assume each URL mapping takes around 256 bytes, we need 100,000 * 0.25 KB = 25 MB per day of storage, or on the order of 10 GB disk space for a year.
Explain any trade offs you have made and why you made certain tech choices...
A spike in traffic could cause the server to be overloaded, autoscaling could benefit.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?