Loading...
write/read ratio: 1:10
write: 100,000 per day
read: 1 million per day
users count: 10,000
URLs stored count: 100,000
memory amount for one URL: ~30 bytes
memory amount for all URLs: ~3MB
cache percent: 80%
peak throughput: ~10 reads per day
GET /long_urls/{shorten_url}(): get long URL from shorten URL and returns id
GET /urls/{long_url}(): get shortenURL from long and returns id
POST /urls (string long_url=null, date expirationDate): creating shortenURL from long URL (can create custom URL) and returns id
PUT /urls/{id} (date expirationDate): update shortenURL and returns id
DELETE /urls/{id} (int shorten_url_id): delete shortenURL
GET /analytics/{id} (): get analytics for shortenURL
GET /redirect/{id} (): redirect from shortenURL to long URL
store URL metadata in relational database like PostgreSQL
indexes with a key of shortenURL and key of userID for fast searching
two tables: user and url
using Redis for caching, where key will be shorten URL and value will be long URL
POST /urls (string long_url=null, date expirationDate): request goes to load balancer, after that by round robin request goes to web server which creates shortenURL, stores it in database and place analytics data into message broker. Analytics service get data from message broker and update database
GET /urls/{long_url}(): request goes to load balancer, after that by round robin request goes to web server which check cache. If cache dismiss request goes to database and retrieve data if it stores in it. After that place data in cache and return to user
GET /redirect/{id} (): request goes to load balancer, after that by round robin request goes to web server which check cache. If cache dismiss request goes to database and retrieve data if it stores in it. After that place data in cache and return redirection to user
We can use least recent usage algorithm for caching in order to store longer more popular URLs
If user wants to create custom shorten URL we must check the absence of this shorten URL in relational database (by index). If this shorten URL exists we return an error. Otherwise we create custom shorten URL in database
Shorten URL creation:
Hashing algorithm allows to create fixed-length URL. In order to handle hash collisions we can use two hashing functions and appending counter if collision happened.
Generating random number can be not unique and because of that we must check the presence of new shorten URL in database. That will increase CPU usage and request latency
Hash function is better than random number because it would be faster creation if we have many URLs in database
Fault Tolerance - each component such as load balancer, web server, database should be replicated. Also monitoring, logging should be adjusted.
Peak request processing - we can dynamically add web servers if we monitor increasing of requests
Expanding analytics information