Loading...
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...
500 M Users
100 M DAU
80/20 read/write
each link is about 50 bytes on average
each new link is about 20 bytes on average
Define what APIs are expected from the system...
login
POST api/v1/login
shorten
POST api/v1/login
redirect
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...
RDB works best for user data
Key Value Store for links
Redis makes sense here for our cache, Cassandra can serve as the main database for all links. Each link will be created with a TTL, so we can save memory overall. But we should have a persistent database that allows us to store the info. Cassandra is optimized for availabilty and partition, which will allow us to have an always available system that can scale. its also low latency in reads
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...
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...
User types in tinyurl link -> load balancer -> api gateway -> goes to tiny url server -> check cache -> check mongoDB if cache miss -> 301/302 moves to new link
User types in link to shorten -> load balancer -> api gateway -> application server grabs key to append to www.tinyurl.com -> adds it to MondoDB -> return ack to user
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...
One important aspect is the shortened url hashes. We have a separate Key generation service (KGS) that does an incremental base62 setup and sends each key to a different application server. This prevents duplicates while also allowing us to have a failsafe. If an application server dies, its okay if those keys are lost forever since there are so many in base 62.
Each link has a TTL, this will have a default of 6 months but can be changed by the user. well have a cleanup service that looks through and deletes old links.
Explain any trade offs you have made and why you made certain tech choices...
KV for links allows for an O(1) lookup. Databases like MongoDB aren't bad choices, but simply not as fast.
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?