Requirements
Functional Requirements:
- Create a short URL for a given long URL.
- Return the long URL associated with a given short URL.
Non-Functional Requirements:
- List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
API Design
- POST /api/v1/url
payload: long_url: long_url
success response: 201 Created
success payload: short_url: short_url
2.GET /api/v1/url
params: short_url = short_url
success response: 200 OK
success payload: long_url: long_url
High-Level Design
- The User (web/app) will send a post request to generate a short url for the given long url, this will be sent as payload.
- The request will pass through an api gateway and based on the route, it will go to the load balancer.
- The load balancer with round-robin configured ( static load balancer) will route the specific request to the Shortening microservice.
- The shortening microservice will create a short url using hash based methods and store the value in the DB (key -value store).
- There will be worker (bull worker if using nodejs) in shortening service that polls for jobs in the redis queue and updated the redis for caching the data with a specific TTL. (This helps in reducing read req to DB)
Detailed Component Design
- API Gateway: This is used so that it can handle authentication and authorization of the user before involving the internal services. Responses can also be cached in the API Gateway. Ratelimitters can also be configured, so that internal services donot get bombarded with requests and protect from DDOS attacks.
- Load Balancer uses round-robin algo to distribute requests among shortening services. This ensures equal distribution of traffic.
- Load Balancer introduces single point of failure, thus for Disaster recovery and minimal downtime, stand by load balancers have to be configured, so that traffic doesnot throttle.
- Shortening service can be a python/nodejs microservice which used hash based algorithms to compute the short url for a given long-url.
- A Key-Value based DB such as AWS Dynamo DB is chosen since we only need to store the short and the long_url. Moreover: there are no relations that need to be stored, hence RDBMS based DB is an overkill.
- KV Based database is great for scalability and availability, with AWS Based serverless based dynamo DB.
- The number of reads to db is decreased due to caching in redis, hence reducing the load and cost to send network calls to DB.