System requirements

Functional:

• Generate short URL for a given long URL
• Redirect to the original URL when the short one is visited
• Track basic analytics (number of clicks, etc)
• Expiration of URLs, custom aliases

Non-Functional:

• High availability (short links should always work)
• Low latency redirection
• Scalability to handle millions of URLs and requests
• Minimal storage cost

Capacity estimation

• Assume 50 million requests/day (both shorten and redirect)
• Peak QPS (queries per second): 500M / (246060) = around 5800 QPS
• Storage estimation: if each short URL mapping is ~ 100 bytes and can expect 10 billion URLs, need ~1TB of storage
• Band width: estimate based on average response size (~ 1KB) x peak QPS for network planning.
• Growth: Plan for 10x future growth in both traffic and storage
• Caching: Use in-memory cache (Redis, Memcached) handle hot URLs and reduce DB load

API design

1. POST /shorten

Purpose: Create a short URL for a given long URL.

Request:

json

Copy

Edit

POST /shorten

Content-Type: application/json

{

"long_url": "https://www.example.com/some/very/long/path",

"custom_alias": "myalias", // optional

"expiry": "2025-12-31T23:59:59Z" // optional

}

Response:

json

Copy

Edit

HTTP 201 Created

{

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

}

Notes:

If custom_alias is provided, check uniqueness.

Validate the URL format.

2. GET /{short_code}

Purpose: Redirect to the original long URL.

Request:

bash

Copy

Edit

GET /abc123

Response:

http

Copy

Edit

HTTP 301 Moved Permanently

Location: https://www.example.com/some/very/long/path

3. GET /analytics/{short_code}

Purpose: Get usage data for a short URL (for authenticated users only, if applicable).

Request:

sql

Copy

Edit

GET /analytics/abc123

Authorization: Bearer

Response:

json

Copy

Edit

{

"short_code": "abc123",

"long_url": "https://www.example.com/...",

"created_at": "2025-05-10T12:00:00Z",

"clicks": 2547,

"expiry": "2025-12-31T23:59:59Z"

}

Optional APIs (for full product):

DELETE /{short_code}: Delete a link (if owned by user).

PUT /{short_code}: Update expiry or destination.

GET /health: Health check for monitoring tools.

Authentication (optional):

If you support user accounts, protect APIs with OAuth or JWT.

Anonymous users may still create links, but won't get analytics/editing.

Database design

We can use a simple table like:

ShortCode LongURL CreatedAt Expiry ClickCount

Options:

SQL: Easy to query, index on ShortCode.

NoSQL (e.g., DynamoDB, Cassandra): Better horizontal scaling.

High-level design

Components:

1. Frontend: For submitting URLs (e.g., React or mobile app).
2. API Gateway: Receives requests.
3. URL Shortening Service:
   • Accepts long URLs and returns short ones.
   • Looks up short URLs and redirects to original.
4. Storage:
   • Stores mappings between short code and long URL.
5. Analytics Service (optional at first).

Request flows

Client → API Gateway → URL Shortening Service → Database

↓

Short URL Returned

Step-by-step:

Client sends a POST request to /shorten with the long URL.

API Gateway routes the request to the URL Shortening Service.

URL Shortening Service:

Validates the URL.

Generates a unique short code (e.g., via base62-encoded ID or hash).

Stores {short_code → long_url} in the database.

Optionally caches the mapping in Redis.

Returns the full short URL to the client (e.g., https://short.ly/abc123).

Detailed component design

API Gateway

• Purpose: Entry point for all client requests (REST APIs).
• Responsibilities:
  • Route requests to proper services (shortening, redirect, analytics).
  • Perform rate limiting, authentication, logging.
• Examples: Amazon API Gateway, NGINX, Kong

URL Shortening Service

• Purpose: Generates and stores the short URL.
• Responsibilities:
  • Validate long URL input.
  • Generate unique short code:
    • Option 1: Use a global atomic counter (e.g., Redis, Snowflake ID generator) and encode using base62.
    • Option 2: Hash the long URL and check for collisions.
  • Store mapping: {short_code → long_url}.
• Persistence Layer:
  • Write to a database (e.g., PostgreSQL, DynamoDB).
  • Optionally cache to Redis for hot links.
• Optional: Support custom aliases and expiry logic.

Redirection Service

• Purpose: Handles requests to short links like short.ly/abc123.
• Responsibilities:
  • Check Redis cache for abc123.
  • If cache miss → query database.
  • Return HTTP 301 redirect to long URL.
• Performance-critical: Optimize for low latency.

Database

• Purpose: Persistent storage for all URL mappings and metadata.
• Choices:
  • SQL: PostgreSQL, MySQL — good for relational integrity, analytics.
  • NoSQL: DynamoDB, Cassandra — great for scale and fast key-value lookups.

Trade offs/Tech choices

Preferred: Base62-encoded ID from Redis/DB or Snowflake — short, scalable, and easy to decode for debugging.

Preferred:

• Use SQL for ease of development and querying if scale is manageable.
• Use NoSQL if you're optimizing for millions of writes/sec, low latency reads, or plan to auto-scale easily.

Preferred: Redis — it supports TTLs for short links and can be used for atomic counters too.

Preferred: Async with Kafka or SQS, with a consumer writing to an analytics DB.

Failure scenarios/bottlenecks

Short Code Collisions

• Cause: Duplicate codes from hash or ID generator issues.
• Mitigation:
  • Use centralized ID generator or Redis atomic counter.
  • Use retry-with-backoff on collision.
  • Add a uniqueness constraint in DB.

Cause: DB crash, connection pool exhaustion.

Mitigation:

• Use replication (read replicas).
• Use circuit breakers and failover.
• Add a retry queue or graceful degradation.

Future improvements

Authentication & User Accounts

• Why: Enables link management (edit/delete), link history, and analytics.
• How: Add OAuth or JWT-based auth, associate links with users in the DB.