System requirements
Functional:
- anonymous users create shortened URL from a user-provided
- users visiting the shortened URL will be redirected the fully qualified URL
- no update, no deletion
Non-Functional:
- highly available, n 9s
- eventual consistent -- uploaded URL will eventually be visible
Capacity estimation
- 10M DAU, average 10 shorten request per day --> 10M * 10 / ~100K = 1KQPS
- 1B click through shortened URL --> 1B / ~100K --> 10K QPS on average, peak might be magnitude more
- URL < 1KB, 10M * 10 * 1KB --> 100GB/day
API design
POST /api/v1/shortenURL
GET /api/v1/redirect
Database design
Do not need transactions/ACID. loose relations. Use NoSQL/KV store
Schema:
Key will be the shortened URL
Value will be
- fully qualified URL
- creation time
- time to live
High-level design
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design...
Request flows
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...
Detailed component design
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...
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?