URL Shortener LLD - Low-Level Design Guide

Design a URL Shortener at the class level using Java. Covers encoding strategies (Base62, MD5), storage model, redirect flow, URL expiry, analytics, rate limiting, and a complete class diagram — built with SOLID principles and OOP design patterns.

1 Hour Interview Coverage Plan

0 - 5 min     Requirements
5 - 10 min    Capacity Estimation
10 - 15 min   API Design
15 - 25 min   High-Level Architecture
25 - 35 min   Database Design
35 - 45 min   URL Encoding + Redirection Flow
45 - 55 min   Scaling, Caching, Rate Limiting
55 - 60 min   Trade-offs + Summary

Introduction

A URL Shortener converts a long URL into a short URL.

Example:

Long URL:
https://codewithvenu.com/blog/system-design/high-level-design/url-shortener

Short URL:
https://cwvenu.io/aB91xZ

Popular examples:

Bitly
TinyURL
Rebrandly
Short.io

What Problem Does It Solve?

Long URLs are:

Hard to share
Difficult to remember
Not user friendly
Bad for SMS/social media
Difficult to track

A URL shortener provides:

Short links
Easy sharing
Redirection
Analytics
Expiry
Custom aliases

Functional Requirements

The system should support:

Create short URL
Redirect short URL to original URL
Support custom aliases
Support URL expiry
Track click analytics
Support user accounts
Delete or disable URLs
Prevent duplicate aliases

Non-Functional Requirements

The system should be:

Highly available
Low latency
Scalable
Fault tolerant
Secure
Durable
Globally accessible

Important expectation:

Redirection must be very fast.

Main Use Case

User submits long URL

↓

System generates short code

↓

User shares short URL

↓

Someone opens short URL

↓

System redirects to original URL

High-Level Architecture

flowchart LR

User --> API[API Gateway]

API --> Shortener[URL Shortener Service]

Shortener --> DB[(Database)]

Shortener --> Cache[(Redis Cache)]

User --> Redirect[Redirect Service]

Redirect --> Cache

Redirect --> DB

Redirect --> Analytics[Analytics Service]

Create Short URL Flow

sequenceDiagram

participant User
participant API
participant Service
participant DB

User->>API: Submit long URL
API->>Service: Create short URL
Service->>Service: Generate short code
Service->>DB: Save mapping
DB-->>Service: Saved
Service-->>User: Return short URL

Redirect Flow

sequenceDiagram

participant Browser
participant RedirectService
participant Cache
participant DB

Browser->>RedirectService: GET /aB91xZ
RedirectService->>Cache: Lookup short code
Cache-->>RedirectService: Cache miss
RedirectService->>DB: Lookup original URL
DB-->>RedirectService: Original URL
RedirectService->>Cache: Store mapping
RedirectService-->>Browser: 301/302 Redirect

API Design

Create Short URL

POST /api/v1/urls

Request:

{
  "longUrl": "https://codewithvenu.com/blog/system-design",
  "customAlias": "system-design",
  "expiryDate": "2026-12-31"
}

Response:

{
  "shortUrl": "https://cwvenu.io/system-design",
  "shortCode": "system-design"
}

Redirect URL

GET /{shortCode}

Response:

302 Found
Location: https://codewithvenu.com/blog/system-design

Get Analytics

GET /api/v1/urls/{shortCode}/analytics

Database Design

URL Mapping Table

url_mapping
------------
id
short_code
long_url
user_id
created_at
expiry_at
status
click_count

Analytics Table

url_click_event
----------------
id
short_code
clicked_at
ip_address
user_agent
country
device_type
referrer

Short Code Generation

Common approaches:

Base62 encoding
Random string generation
Hashing
Snowflake ID + Base62
Database sequence + Base62

Base62 Characters

a-z
A-Z
0-9

Total:

62 characters

If short code length is 7:

62^7 = 3.5 trillion combinations approximately

Encoding Flow

flowchart LR

UniqueID[Unique ID]

-->

Base62[Base62 Encoder]

-->

ShortCode[Short Code]

Example:

ID: 12567891

↓

Base62

↓

aB91xZ

301 vs 302 Redirect

Redirect	Meaning	Use Case
301	Permanent redirect	URL never changes
302	Temporary redirect	Analytics and flexible redirection

For URL shorteners, 302 is commonly preferred because it allows tracking and future changes.

Caching Strategy

Most traffic is read-heavy.

Create URL = low traffic

Redirect URL = very high traffic

Use Redis cache for shortCode → longUrl mapping.

flowchart LR

RedirectRequest

-->

Redis

Redis --> OriginalURL

Redis --> Database

Cache Benefits

Faster redirects
Lower database load
Better scalability
Lower latency

Analytics Design

Analytics should not slow down redirection.

Bad design:

Redirect

↓

Update analytics synchronously

↓

Slow response

Better design:

flowchart LR

RedirectService

-->

MessageQueue

-->

AnalyticsService

-->

AnalyticsDB

Rate Limiting

Protect APIs from abuse.

Apply rate limits on:

URL creation
Custom alias creation
Analytics API
Suspicious traffic

Example:

100 URL creations per user per hour

Security Concerns

The system should protect against:

Malicious URLs
Phishing URLs
Spam
Brute force short code guessing
Abuse by bots
Open redirect misuse

Security measures:

URL validation
Safe browsing checks
Rate limiting
Abuse detection
Blocklist
User authentication for advanced features

Scalability

Read Scaling

Use:

Redis cache
CDN
Read replicas
Partitioning
Global edge routing

Write Scaling

Use:

ID generator service
Database sharding
Queue-based analytics
Async processing

Availability

Redirect service must be highly available.

Use:

Multiple service instances
Load balancer
Multi-AZ deployment
Database replication
Redis cluster
Failover strategy

Final Enterprise Architecture

flowchart TD

Client[Client / Browser]

Client --> LB[Load Balancer]

LB --> Redirect[Redirect Service]

LB --> API[URL Management API]

API --> IDGEN[ID Generator]

API --> DB[(URL Database)]

Redirect --> Redis[(Redis Cache)]

Redirect --> DB

Redirect --> Queue[(Kafka / SQS)]

Queue --> Analytics[Analytics Service]

Analytics --> AnalyticsDB[(Analytics DB)]

API --> RateLimiter[Rate Limiter]

Redirect --> Security[URL Safety Check]

Capacity Estimation

Assume:

100 million URLs created per month
1 billion redirects per day
Read-heavy system

Read/write ratio:

Redirects : Creates = 100 : 1 or higher

This means caching is critical.

Common Bottlenecks

Problem	Solution
Too many redirects	Redis cache
Database overload	Read replicas + sharding
Analytics slowing redirect	Async queue
Duplicate short codes	Unique constraint
Abuse/spam	Rate limiting + validation
Hot URLs	CDN + cache replication

Best Practices

Use Base62 for short code generation.
Keep redirection path extremely fast.
Use Redis for popular URLs.
Process analytics asynchronously.
Use 302 redirects when tracking is needed.
Add expiry support.
Add rate limiting.
Store click analytics separately.
Monitor latency and error rates.
Avoid synchronous heavy processing during redirects.

Interview Questions

How do you generate unique short URLs?
Why is Base62 used?
What is the difference between 301 and 302 redirect?
How do you scale redirects?
How do you prevent duplicate short codes?
How do you track analytics without slowing redirects?
How do you handle hot URLs?
How do you protect against malicious URLs?
How would you shard the database?
How would you design this system globally?

Summary

A URL Shortener is a classic High-Level Design problem because it covers:

API design
Database design
Unique ID generation
Caching
Redirection
Analytics
Rate limiting
Scalability
Security
High availability

The most important design principle is:

Redirection must be extremely fast and highly available.

A production-ready system uses:

URL Shortener Service
Redirect Service
Redis Cache
URL Database
Async Analytics Pipeline
Rate Limiting
Security Validation
Monitoring

This design pattern is useful for building large-scale systems like Bitly, TinyURL, marketing campaign tracking, affiliate links, SMS links, and enterprise link management platforms.