Requirements

Functional Requirements:

• User send a long URL.
• System take that long URL
• and return a unique short URL which will work exactly the same.
• URL Directing: given short URL => redirect to the original URL.
• user should be able to provide an optional custom alias for their short URL.
• Support a default or user specified expiration date for links
• Track and store click statitsics for each shortened link.

Non-Functional Requirements:

• High Availability : The service must be always up so people can send their long URL and get a short URL.
• Scalability: The system should be able to handle a large volume of requests.specificaly, it should scale horizontally to support an increase in number of read (redirections) and write requests(shortening)
• Low Latency : Retrieving the short URL must be instant.
• ShortURLs should not be easily "gussable".
• Durability : Once Long URL added, it shouldnt be lost.

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

APIs for URL shortner :-

• POST /v1/shorten

Request : {"longUrl" : "https://longUrl", "alias" : "testLongUrl"}

Response: {"shortLink": "https://shortLink"}

• GET /v1/{shotURL}

Request: {"shortURL": "https://shortURL"}

Response: {"LongURL": "https://LongURL"}

Status Codes :-

200 for success with response,

400 get as a non existing URLs,

302 for redirecting to original URL

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Here are my components in this HL Design :-

1. Client
2. Load Balancer
3. API Gateway
4. Application Server
5. KGS (ID/Key generator Service)
6. Database
7. Cache (Redis Cache)
8. MQ (Message QUEUE - Kafka)
9. AS (Analytics Service)
10. ADB(Analaytics Database)

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Here are my components in this HL Design :-

1. Client
2. Load Balancer
3. API Gateway
4. Application Server
5. KGS (ID/Key generator Service)
6. Database
7. Cache (Redis Cache)
8. MQ (Message QUEUE - Kafka)
9. AS (Analytics Service)
10. ADB(Analaytics Database)

Client :- Client is nothing but a user or a customer who wish to generate a short URL.

Load Balancer :- Load balancer will distribute the load , if there millions of request and there are few instances are idle, this component will help to choose the right instance and call it. Load Balancer should be scaled across multiple availability zones.

API Gateway :- API Gateway will act as a single entry point. It will help us to route the request to particular service. This will handle SSL termination, rate Limiting (to prevent DDoS/abuse). API Gateway also should be scaled across multiple availability zones.

Application Server:- This is where our actual code will be. Application server manages the business logic. It receives Long URLs, request a unique ID from the KGS, and stores the mapping in DB. Application server also receives short IDs, where it will check the cache if available it return or else check DB and issues a 302 Redirect.

KGS(ID / Key Generation Service):- This ensure every shortened URL gets a unique, non colliding ID. Pre-generates random 6-8 character strings (Base62 encoded.

Database(NoSQL):- We were storing URL mapping here. permanent storage for URL mappings.

why NoSQL (MongoDB) :- It scales better for simple key-value lookups and can handle billions of records more easily then a traditional SQL Database. and it has dynamic , flexible schema.

Cache (Redis Cache) :- for frequent access we can store our data in cache, so it drastically reduces latency for redirects. and it reduces DB load.

MQ Messaging QUEUE(Kafka) :- to store all click events we were using MQ - kafka. It helps decoupling the redirection logic from the analytics logic. When a linked click , the server produces a message to kafka and redirects the user immediately. This prevents analytics processing from slowing down the user experience.

AS (Analytics Service) :- It will be act as consumer.

Consumes events from kafka (ex - "Link x clicked from NYC at 2 PM)

ADB(Analytics Database):- This is also a DB to store all the events.

whatever events analytic service consume , that will store it in here Analytics Database , so in future we can track this.