Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
1)service containing apis to create the url shorteners and retrieve them when asked
2) a simple table mapping the url short link id to the real url
3) a random id generator we can rely on uuid service -> we will make sure no duplicated we will have a check on that we dont need complex indexing for now as we already have is. aismple two column table for now
List the key non-functional requirements (performance, scalability, reliability, etc.)...
1) a 200ms response time at 95th percentile and high availability like 99.9% of time
2) a replica based db with server available across multiple key parts
3)system should support easily configurable to add more dbs and application servers (auto scaling enabled)
4)initially we can expect low traffic as the site grows , we keep on having observability alert stats when we are reaching 80% close to a limit then we update review the system
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
1) create -> revieves url -> generate uuid make sure its not there alreadys
and table will have uuid( 4 len ( mix of nums, symbols, and alphabets )-> url -> and an automatic system to for the chars to go from 4len id to 5 len uuids based on a threshold of say x no of alreadys exist in y of time
2) a scheduler to identify if the uuids crossed x of time expire them
3) retrieve api to get them out based on uuid -> and form the real url to redirect
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
1) create -> revieves url -> generate uuid make sure its not there alreadys
and table will have uuid( 4 len ( mix of nums, symbols, and alphabets )-> url -> and an automatic system to for the chars to go from 4len id to 5 len uuids based on a threshold of say x no of alreadys exist in y of time
2) a scheduler to identify if the uuids crossed x of time expire them
3) retrieve api to get them out based on uuid -> and form the real url to redirect
no specific data sytcutures, we just store a sin gle table