Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
1:1 mapping between original URL and the short URL.
anaylitics requirement on the click tracking, user engagement, demographic insights, time of access.
User can set custom_alias
List non-functional requirements for the system...
Low latency
High availability
Eventual consistency
Estimate the scale of the system you are going to design...
100,000 DAU, 30% adds new URLs daily, supports 10 million unique URLs
100 QPS
64GB storage
Define what APIs are expected from the system...
Shorten URL
POST: /shorten
Request Body: {
"url": ""
"custom_alias":
}
Response
{ "shortened_url": "https://short.ly/myShortLink", "original_url": "https://example.com"}
Retrieve Original URL
GET /{alias}
{ "original_url": "https://example.com", "click_count": 1500}
Delete Shortened URL
DELETE /{alias}
{ "message": "Shortened URL deleted successfully."}
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your 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. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
We can have the following components in the system: An API Gateway integrates load balancer, rate limiting; An application server processes the user request; A DB to store the URL mapping; a Redirect service to redirect URL; A cache between DB and application server to store frequent accessed urls; The analytics service to process the logs; The Message queue between application server and analytics service to asynchronously send logs of user accesses; the Analytics Database to generate aggregated data to meet analyticall requirements.
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...
Database should be replicated. The replication strategy can be single leader replication, since we have low write and high read. Write can be done to the leader, while read can be done from all the followers.
The application server sends log of user behavior through MessageQueue asynchronously to the analytical service. The analytical service store it to the analytical DB and it would generate aggregated data.
Explain any trade offs you have made and why you made certain tech choices...
DB replication single leader strategy ensures low latency and high availability while traded off consistency to be eventual consistency.
Try to discuss as many failure scenarios/bottlenecks as possible.
If one of the App server failed, we can bring up new instances quickly as the server is stateless. If the DB replica fails, we can bring up new instance loading the replica soon. If the leader fails, we can elect a new leader.
The bottleneck of the system is reading from the DB. We add replicas to be read from, also we can have a cache between application server and the DB to store the popular urls.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
Writing to DB still takes a long time as we need to check if the alias exist. We can split the alias into different spaces, for example by user.