Loading...
User can get a short URL after providing a regular URL
User can retrieve regular URL after providing a short URL
Highly consistent
Highly available
low latency response (1 second)
write much more than read.
1 million active users, 10 shorts per user per day, 2 redirection requests
which translate to
200 queries per second for white
2000 qps for read
calculate the storage:
20 million URL , each 1kb , 2GB per day 1TB, year
GET /v1/originalrul
param : short URL
return : string of original URL
POST /v1/shorturl
param : original URL
return string of shortURL
since no acid needed, so I choose no SQL as its easy scale.
key value no sql database
key : short url key
value of original url
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...
write path :user request a short URL with original URL, shortURL service prove a short URL and return it to front end, and save to to no sql database.
read path : user provide a short URL to read service and read service query databse and return the original URL
short URL generate:
character to user: 1-9 , a - z, A- Z total 62 character we could use
8 character : 62 to the pow of 218 trillion
take unique id generator by snowflake random generate for us.
handle duplicate: once short_URL_generator generates shortURL ID, we use bloom filter to check if that's already in the database.
bloom filter is a probity check if key is in the set/ database.
if bloom filter return true - item not in set/ database no duplicate 100% accurate. add the key to database
if bloom filter return false - item in the set - not 100% accurate, regenerate the short URL.
check is constant time.
all the servers has redundancy, if one server down, redundant server replace.
we could use white after cache between 2 servers and database, read and write all go to the cache and cache handles persistence of data to database. This improve latency.
Trade off is that considering the senario where cache is down before write to database: we can use write ahead log to handle that.
further improve latency we could use CND or we can use geolocation of server and database.
redundancy servers takes care of the server failure.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?