Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
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...
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.
when a user sends a post request through our frontend service our api will create a hashmap with pairs of the key of the short generated code and the value being the actual url that the user will be directed to. when generating codes, we have to account for collisions and what character will be able to be generated ex(base62). we generate randomly and retry on collision
On get request from our frontend service our api will send a request to the cache and return the long URL on hit. on a miss the load balancer disperse the request to datastores. the datastore will then reurn the long URL based on the request
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 a simple service(no login)
we will use NoSQL as it is faster and we will likely not be doing any joins as there will only be key value pairs
data:
primary key is the unique short url string , the value is the long url string
when sharding we will have a replica on another data store to improve durability if we miss on the owning shard we can divert to the replica
the short code is the lookup key and we shard by the short code as well
we also make use that the shard is created and any duplicate request are terminated
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
ID-gen:
Codes are generated on the client's end, then checked against our API backend for collisions; if a collision occurs, we regenerate the code and recheck on each failure. This lets the user create a custom code. We can disregard the guessability of the URLs, as users who create custom entries would likely want them to be self-explanatory. Random keys can't be enumerated — this protects links users consider private.
Caching:
We can use a first-in, first-out method for caching, keeping the most frequently used URLs easily accessible, while booting the ones that are no longer being used can be redirected to the datastore.
Hotspot mitigation:
To prevent a node from becoming overburdened, the load balancer can divert traffic from a primary shard to a replica