Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
When you input a link, you get a hashed shorter link
When you use/access that shorter link, it always gets you to the original link
List the key non-functional requirements (performance, scalability, reliability, etc.)...
Tiny links need to be unique even at scale
We want accessibility, its ok if stale links still work
in terms of scalability, depends on users but we probably need to make billions of links a year
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
billions of links created a year needed
storage/db needs to be able to store that
more read heavy
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...
POST links/{link}
GET links/{short_link}
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.
client to load balancer to rate limiter to api gateway with our get and post calls to server, which can encrypt the links and have a cache for reads and queue for writes.
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...
basic sql postgres 2 column with the hashed link and the original link. can shard once our db is too large.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
lets dive into the hashing. u use an encoding algorithm