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

1. Create Short URL (Write Path)

POST /shorten

Request Body:

{

"long_url": "https://example.com/very/long/url",

"custom_alias": "optional_custom_code" // optional

}

Response:

{

"short_url": "https://short.ly/abc123"

}

Description:

• Accepts a long URL and optionally a custom alias.
• Generates the short code.
• Stores mapping in DB.
• Returns the shortened URL.

2. GET /{shorten_URL}

Response:

{

"long_url": "https://example.com/very/long/url",

}

Description:

• Accepts a Short URL
• Checks Mapping in Cacche and if fails then in DB.
• Returns the Long code.

High-Level Design

Overview:

Create short URLs from long URLs.

Redirect short URLs to the original URL.

URL SHORTENING for LONG URL:

Request Flow – Write Path (Short URL Creation)

Client sends POST /shorten request with a long URL.

Load Balancer distributes the request across stateless App Servers.

API Gateway handles routing, authentication, and rate limiting.

ID Generation Service generates a unique short code (Base62 encoding, or distributed ID like Snowflake).

Shortening Service:

• Validates input
• Stores mapping in sharded, replicated database
• Caches the mapping in Redis for fast future reads
• Response: Returns the short_URL.

Redirect SHORTENED URL:

Request Flow – Read PATH (Short URL READ)

Client sends GET /{}reqshort_URL}

Load Balancer distributes the request across stateless App Servers.

API Gateway handles routing, authentication, and rate limiting.

REDIRECT SERVICE looks for short_URL in Cache and if it is there it is returned, otherwise it is queried into database.

ZOOKEEPER Each Shortening request is given to zookper so even if there is concurrent reuest it is appendent inti a queue and then unique id can be assigned and they can be treated without difficulty.

Detailed Component Design

High Availability: Load balancer + stateless app servers + DB replication.

Low Latency Redirects: CDN + Redis cache.

Horizontal Scalability: App servers, DB sharding, Redis cluster.

Viral Link Handling: CDN + replicated hot keys + async click updates.

Concurrency / Collision-Free IDs: Distributed ID generation + message Queue + DB constraints.

Key Architectural Patterns

• tateless service → horizontal scaling behind load balancer.
• Caching (Redis) → reduces database load, enables low-latency lookups.
• Sharded & Replicated Database → durability, scalability, and high availability.
• Separation of Concerns → distinct services for URL creation, redirection, and ID generation.
• Shortening Service: It will be used to generate unique id for each request. The ID will be used

Cache Handling:

• Populate Redis cache on insert.
• Cache TTL to prevent stale entries.
• Support manual purge / update for URL disable or edits.