Loading...
List the key non-functional requirements (performance, scalability, reliability, etc.)...
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...
/url-creation {base-url} -> minified url
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.
We will need a hashing algorithm to convert urls into some hash. we can use 26+10 (letters+numbers) 36^8 ~ 2.8 trillion urls so we have 8 digits to represent our url somehting like logly/abc123z4
'
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...
For replication we should look to leader based replication due to the high read load on the server. Multiple leader replication strategies are not ideal due the un durable writes that can occur due to the presence of multiple leaders writting
we can store the user details like user-id, name, creation,
url
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.