Loading...
40 reads to 1 write ratio
POST /urls
body {
"long_url" : "msc",
"custom_alias"? : "msc",
"expiration_date" : "msc"
}
GET /{short_code} -> redirects to long_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.
The client send POST /urls to the API gateway. Users will be rate limited at the point if they send too many request. The API Gateway will route that the the server where it will validate the URL. It will make sure the url isn't on a block list for example if that was a feature. If the client contains a custom alias with its input it will right that as the short code only if the alias isn't taken. It will return a 409 error if it is taken. If no alias is added the it will instead go through our random ID generator which would just be a counter to handle the short_code uniqueness. Once our short_code is created it will be add to our database as a key value pair. The key being or short code and our value being our long URL. If created successfully it will return a 201 created response and also our short url.The client sends GET /short_code which will be rate limited at the api gateway if needed. Once the passed the api gate way our short code format will be validated at our API Server. Our server will then check redis if our cache contains our read. If its a cache hit then our request will go straight to our messaging queue to handle our click event. If it's a cache miss then we'll read from our key-value database and then fill the cache with a Time-to-Live item. If our short_code doesn't exist our server will return a 404 error. If it expired, then it will return a 410 error. Once in our message queue and out request is on top we'll be redirected to our long_url. Our API response will be 302.
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...
NoSQL database, Key-Value Database specifically.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
If there is no custom alias present the short_code will be generated by the ID generator. Well use a counter and redis ICNR as a constant. This will then be encoded into a 7 character code base62 style giving us over 3million different unique codes. Each server will grab a rang of ids that way no server ever uses the same short_code. To keep redirects under 100ms I'll makes the lookups one key read to the key value store. I'd also put redis cache aside layer in front with a LRU cache eviction and a time to live since reads are skewed to mainly popular links. I'd have click analytics published to the queue asynchronously so the redirect never waits on them. For global users I would deploy regionally to cut network latency. To protect against cache stampedes I'd merge overlapping cache updates.