Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
User should be able to give a long url and get back tiny url
when given a short url, user should be able to retrieve long url and get redirected.
User should be able to give custom url and specify validity time
Latency should be with in 100 milliseconds both for read operation, with in 500 milliseconds for write operations
System should be highly avaialble with 99.999% uptime and minimal downtime
System should be secure
System should be able scale well for billions of URL
System should provide non predictable short alias, and the alias should be unique.
Define what APIs are expected from the system...
POST /v1/urls/
Request body:
longurl
custom alias
expiry
response: 200 success or 201 created
Response body: short alias
GET /urls/{shorturl}
302 redirect with long url
error if it was expired or not found.
Client could be mobile application or desktop, it sends request to API gateway, Clients use domain name to address the system, DNS helps resolve the address and route to API gateway. API gateway does the rate limiting, authentication, and routes the request to appropirate microservice in this case shortening service and redirection service based on request. In shortening use case the request is forwardde to loadbalance fronting the shortener service. Shorter service runs on multiple instances of servers which is microservice, so it helps hortizontal scaling, high availability better performance and low latnency since the workload is distributed and avoid single point of failure. Now shortener sevice takes the long URL and converts to short alias and stores it in NoSQL DB for low latency and high scalability. when request comes to redirect service it refers the DB and sends back the long URL. For ID generation there are two approaches one is to use hashing algo like MD5, SHA256 etc that takes long URL generates the hash and pick up the first 7 or 8 characters to be short alias. Problem with this approach is collision. There are some approaches we can workaround this by adding salt but better approach is to use ID generator service. shorterner service talks to ID generator service whos sole responsibility is to provide unique ID that is not predictable, and use the ID and generate base 62 encoding. Redirector can also use Redis cache ( key value store cache or distributed cache hash table) , so it first refers the cache if not available it will rfer the data base and update the cache.
As expalined above
API gateway does the rate limiting, authentication, and routes the request to appropirate microservice in this case shortening service and redirection service based on request. In shortening use case the request is forwardde to loadbalance fronting the shortener service. Shorter service runs on multiple instances of servers which is microservice, so it helps hortizontal scaling, high availability better performance and low latnency since the workload is distributed and avoid single point of failure. Now shortener sevice takes the long URL and converts to short alias and stores it in NoSQL DB for low latency and high scalability. when request comes to redirect service it refers the DB and sends back the long URL. For ID generation there are two approaches one is to use hashing algo like MD5, SHA256 etc that takes long URL generates the hash and pick up the first 7 or 8 characters to be short alias. Problem with this approach is collision. There are some approaches we can workaround this by adding salt but better approach is to use ID generator service. shorterner service talks to ID generator service whos sole responsibility is to provide unique ID that is not predictable, and use the ID and generate base 62 encoding. Redirector can also use Redis cache ( key value store cache or distributed cache hash table) , so it first refers the cache if not available it will rfer the data base and update the cache.
with NoSQL, paritioning or sharding helps distribute the data. We can partiion based on short alias, so each redirect will reach exactly one shard. There could also be replication so in case of if disaster failover can switch the access to replicas.
When one alis agoes viral, the redis will help take the cache hit and avoid reaching data base.
API gateway helps ratelimit, and log metrics.
URLMapping
shortURL
createdDate
expiry
longURL
Clients sends longURL in the POST request, authn and authz are out of scope but assume the auth token is provided in the request, the API gatway authenticates and sends the request to shortening service, the shortening service makes internal grpC call to ID generateror service and gets the ID , and applies base62 encoding to get the shortURL, it then stores the URLMapping the noSQL data base and returns response to the client.
Now when the client sends redirect request, the redirect service will refer the redis cache if its available it will retrieve the record and check for expiry. If is expired it will return appropriate error code. If not found in redist it will query the data base and update redis cache and then return the response.