List functional requirements for the system (Ask the chat bot for hints if stuck.)...
List non-functional requirements for the system...
Estimate the scale of the system you are going to design...
Pointless imo
Define what APIs are expected from the system...
post/url {
expirydate:None
} -> shortened url
get/shortenedUrl -> returns original url
delete /shortenedUrl
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...
We will use DynamoDB to essentially map shortened url to actual url
data is like this
key: TinyURL
Value: URL
TTL: 5 years (default)
CreationDate:
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 wil use a loadbalancer and api gateway to direct the traffic to the right server and apis.
We will use dynamodb to store the mapping for tiny url to url.
We will use sha256 to hash the url to create the tiny url. Maybe we will give an option to user to create their own url which we will validate (ensure it does not already exist)
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...
Workflow is like this:
Client input a url and hits a create tinyUrl button.
the url will go thorugh a loadbalancer and api gateway.
It will then go to the createTinyURL service which will use sha256 hashing to generate a tinyurl.
it will then store the url in the dynamodb database using the tinyurl as a key.
When client searches the tinyurl in the browser, it will go throuhg the apigateway/loadbalancer, then it will hit the getTinyURL service. It will then retrieve the url from DynamoDB.
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...
We will add caching (most recently use strategy) and CDN to improve the speed . Most recently used shoud be good cause for the most part, when someone creates a tiny url, they want to use it right away.
Sha256 for hashing
Explain any trade offs you have made and why you made certain tech choices...
We use DynamoDb instead of relational database because it scales better. We also do not plan on doing queries on the data so sql is not really needed. We basically just need a mapping of key to value
Can also potentially use redis with a TTL
Try to discuss as many failure scenarios/bottlenecks as possible.
If multiple users use the same url. for every url request we can append a counter at the end to ensure each one is unique. Or if we have users, we append the user to the end to generate the url.
We will need to partion data since we will have lots.
We can partition data from consistent hashing.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?