Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.
• Custom alias Support
• URL Redirection 302
• Phishing URL Check
• Analytics and Tracking
• Invalid or expired URLs.

Non-Functional Requirements:

• System should be highly available
• Scalable
• system should be highly performant
• system should be secured
• the system should be consistent

API Design

There would be two kinds of APIs:

1. One for getting the URL
2. One for posting the URL

That means you give the long form of the URL and expect or sort from the URL.

POST /user/{id}

{

"originalUrl":"",

"type":"custom"

"newUrl":"",

"expiredAt":""

}

The feature for original URL or custom URL would be for premium users. They can pass a new URL and an expired time as well. For the general user, only post call would be with the original URL, and the response would be the new URL with expired time.

POST /user/{id}

{

"originalUrl":""

}

GET /url/{short_url} => would return the original URL with expiration time

Response :

{

"originalUrl":"",

"type":"custom/normal"

"newUrl":"",

"expiredAt":""

}

High-Level Design

For the high-level design, what I have thought is:

• Client requests will fall directly on E-Pay Gateway.
• From E-Pay Gateway, the call will fall from the load balancer.
• From the load balancer, there will be a URL sorting service.
• URL sorting service will sort the URL based on certain logic or the business logic.
• It will process the user URL into DB, and it will cache the data as well for the URLs that have been sorted and entered to the client.
• Similarly, once the document has been sorted, it will also drop an event in SQS.
• From there, the analytics service will get that event, and we'll process it for the analytics one, and we'll save that in Analytics DB.

Detailed Component Design

One of the detailed component designs in the URL shortening service will be how we shorten the URL. One approach would be to use the DB auto increment ID, but that will be the bad approach, the worst approach, so we'll not go ahead with that.

One approach would be that there will be a service that will pass that value, the URL hash, since every URL will be unique. Let's suppose two users come with the same URL, the same kind of URL, so we want them to return a particular URL, right?