Loading...
User should be able to write a full URL and receive a short alias
User should be able to request the short alias and get the original full URL
Sytem should implement rate limiting to prevent spam
System should prioritize low redirect latency
System should handle ~100:1 read-to-write ratio. Let's say initially we want the site to support 100 million DAU. So that would mean 100 million reads and 10 billion reads / day. For storage we have: short aliases (7B) + long urls (100B) + timestamps + counter + index overhead = 300B. So we then have 100M * 300B = 30 GB/day or 11 TB / year.
POST /v1/urls
{
"text" : url
} -> response : {"text": alias}
GET /v1/urls/alias -> url
DELETE /v1/urls/alias
We can implement a URL shortening service via a simpel monolithic architecture. We have a client that interacts with a REST API gateway, which then communciates with the server or rate limiter if it's spamming. The server itself will be responsible for two main components: alias creation and URL redirect. On URL creation, a hash is generated for the URL and stored as a pair or map in the SQL database. On URL redirect first the cache is checked if the map is there, if not the request is forwarded to the database. The cache eviction policy would naturally be LRU so that popular URLs are cached continually and redirected quicker. This will also decrease redirect latency a main requirement of our system.
The server could use a hash alogorithm to generate hashs that can be appended to the domain URL like how TinyURL does it. The hash and the full URL of the site are then stored in the database.