Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
1) url generation with 200WPS.
2) GET shorten url with 20K RPS
List non-functional requirements for the system...
Estimate the scale of the system you are going to design...
~300GB new urls can be created in a a year
Lets suppose we take 8 character for shortened url to store new shortened url then 8 bytes *300GB i.e approx 2TB of data per year for storage.
Define what APIs are expected from the system...
GET API - /v1/shortenUrl/getShortenUrl/{urlPath}
POST API -
/v1/shortenUrl/createShortUrl
Body=
{ long-url-Path-
expiration date-
}
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
We will take no sql Db say Couchbase to store shortened to long url mapping as we have to support around 2TB of data per year
We will take SQL data to store the newly geenerateds short url with isAvaialble column
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
user hit request to generate the url shortner. The server will call the url shortner service which will give 1 shortned url from lot of avaialble url in memory. If no available memory is present then servcie will directly call DB to fetch one url. It will then map this shortned url to long url and save in no SQL DB with expiry time.
Now when user comes next and ask for short url it URL shortened server will first look in Redis cache. If it is not available there it will fetch the same in DB and then save in cache also . Redis cache will work in LFU cache.
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
If in future the load increases we can split the no sql server to more server behind load balancer horizontally to scale.
for server if the request load increases we can have load balancer behind the server also and can serve the request in distributed fashion.
For url shortner generator we can use optimized locking while fetching the url from the in memory cache so that no parallel request are getting same shortened url. for SQL DB we don't need that locking as SQL already supports the ACID property. With column of used and unused we can reuse the used shortned url so that we dont have to create new url again and we can run the batch weekly once that will fetch all teh urls fron no SQL DB for which expiration has already reached and update those urls with used=true in SQL DB.
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?