size of database = num of original URL * num of corresponding short URL.
100 reads with 1 writes.
If encode a url with 64-bit hashing, for one write per second, assume 10^5 seconds/day, each day will occupy 800MB. For 100 reads/seconds, the service needs to be scaled.
GenerateShortURL(original_url, user_id): POST tinyurl.io/generate_url
RetrieveLongURL(short_url): GET tinyurl.io/retrieval_url
Redirect: GET tinyurl.io/short_url, return 302 and redirected, or return 404
NoSQL key-value store
When request come in, it first hit the load balancer which will take the RR stateless algorithm to distribute the request to one application server.
The server will first check the LRU cache to find the cached url mapping and get corresponding short url. If can't find in cache, the server will search in the Database and create a key-value pair if no mapping existed.
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...
We have a hash function to generate each shortened url so that every time a post request coming, a hashed value is calculated and being checked within the database.
Consistency, Latency and Availability. We want both any write request is not lost and latency is less than 20ms.
Number of Database Node, server, load balancer and latency.
Elastic search could be applied to improve the existence checking process.