Loading...
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...
Two routes, one POST, one GET with the following structure
POST /shortenURL
GET /shortURL/{uuid}
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.
The client would provide a long URL that will be send to the route POST /shortenURL, the backend would receive it and generate a shorten version (either handled internaly with specific method or via a library to encode the URL). The long URL would be stored in DB in a table with the following structure :
To avoid duplicates, when can generate an idempotence key, this will avoid multiple creation (lost response, unstable connexion cases).
The responses of the POST would return a 200 if properly shortened or an error if anything occurs (duplication for exemple, existing already in DB)
The GET route would return the shortened URL created
To improve the system, we could implement a caching system (redis for exemple), by hitting the cache instead of the DB for each redirection it would reduce the charge on the Database load. The cache strategy I would advise is the lazy load, checking first in the cache before accessing the DB. A TTL must be put in place depending the demand for redirection. If the cache is hit we increase the TTL of the cache value, if not after 1mn we can erase it
By defining a load balancing strategy, we would allow a horizontal scaling strategy. To avoid database overload and defining such strategy we are lowering the number of request made to the primary databse. We could use a primary DB solely used for writing and create multiple replicas allowing read-only queries such as GET queries.
A rate limiting strategy can be definied to avoid possible malicious attack on our servers. For exemple by defining a tokenized strategy and allocating a fixed numbers of tokens allowing the user to interact with the cache system and the DB, we are limiting the number of calls. A new token can be given each second ensuring a smooth experience to the user will preventing malicious one to try things such as 1000 calls per seconds
We can implement multiple points of observations. For exemple we can track the number of errors generated by our API routes but also observe in live our caching system live.
For the API routes an error observability strategy can be put in place, as the system must be highly reliable we can put a p99 rule which would trigger an alert to the tech team if less than 99% of the request are going through correctly
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.