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)

High Level Design Flow :-

  1. Entry Point :- Requests enter through a Load balancer and API Gateway, which handle rate limiting and route traffic based on the endpoint (/shorten vs /redirect).
  2. Write Path:- (shortening) The Application server fetches a unique ID from the KGS(ID generator). it store the mapping in the noSQL DB and populates the redis cache.
  3. Read Path:- (redirection) The server performs a cache-aside lookup. It checks redis first, on a miss , it quires the DB. The user is then redirected via an HTTP 302 status code.
  4. Analytics :- To maintain low latency, click events are sent asynchronously to kafka. An analytics service consumes these events and persists them into a dedicated analytics DB.





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.

Database Partitioning & Sharding :-

To scale to billions of URLsm we use Hash-based partitioning, The short_url_id act as the partition key. this ensures an even distribution of data across database shards and prevents any single node from reaching its storage or I/O limits.

Advanced Rate Limiting :- To protect the system, the API gateway implements a token bucket algorithm. we set different tiers: stricter limits for the POST /shorten (write path) to prevent database bloat, and more generous limits for GET (Read path) to ensure high availability for legitimate users.

Hotspot Mitigation:- (Caching strategy) for viral links (hotspot), we employ redis replication. Popular keys are replicated across multiple read-replicas, We also use consistent hashing in our load balancer to ensure that if a cache node fails, the load is redistributed minimally without a full cache wipe.

Reliability :- We implement Resilience4j on API server service. if the DB or KGS or cache unresponsive , the circuit opens to prevent a cascading failure, returning a "Service Unavailable" message quickly rather than letting requests hang.