HLD: Design TinyURL

# Functional Requirements:
1. Long URL — Short URL (e.g., tinyurl.com/abc123)
2. Short URL — Long URL (redirect)
3. Custom aliases (optional)
4. URL expiry (optional)

# Non-Functional Requirements:
1. Low latency (< 100ms redirect)
2. High availability (99.99%)
3. Not guessable short URLs
4. Analytics (click tracking)

# Capacity Estimation:
- Write: 100M URLs/day = ~1200 writes/sec
- Read: 10:1 read:write ratio = 12,000 reads/sec
- Storage: 5 years — 100M — 365 — 100 bytes = 182 TB
- Bandwidth: 12K reads — 500 bytes = 6 MB/s

# High-Level Architecture

Client (Browser) — Load Balancer — API Gateway
 — URL Service (creates short URL)
 — Redirect Service (redirects to original URL)
 — Analytics Service (tracks clicks)
 — Cache (Redis for hot URLs)
 — Database (stores URL mappings)

# API Design:
POST /api/shorten
 Request: {"long_url": "https://very-long-url.com/path", "custom_alias": "my-link"}
 Response: {"short_url": "https://tinyurl.com/my-link"}

GET /:short_code
 Response: 301/302 Redirect to original URL

# Option 1: Hash-based
? MD5/SHA256 of long URL — take first 7 chars
? Problem: Collisions (same hash for different URLs)

# Option 2: Counter-based
? Global counter — convert to Base62
? Counter 1 — "bT3" (Base62)
? Problem: Predictable, sequential

# Option 3: Pre-generated Key Service (KGS)
? KGS generates unique keys offline
? 1 billion keys pre-generate karo
? Service se key lo, URL map karo
? BEST PRACTICE!

# Base62 Encoding:
? Characters: a-z, A-Z, 0-9 (62 chars)
? 7 chars = 62^7 = ~3.5 trillion unique URLs
? Enough for 5 years at 100M/day

# Key Generation Service (KGS):
? Two tables: unused_keys, used_keys
? KGS continuously generates keys
? When service needs key, unused se lo — used mein daalo
? KGS has 2 replicas for redundancy

# SQL Schema:
CREATE TABLE urls (
 short_code VARCHAR(7) PRIMARY KEY,
 long_url TEXT NOT NULL,
 user_id INT,
 created_at TIMESTAMP,
 expires_at TIMESTAMP
);

# Index:
CREATE INDEX idx_long_url ON urls(long_url);

# NoSQL Alternative (DynamoDB):
{
 "short_code": "abc123",
 "long_url": "https://very-long-url.com/path",
 "user_id": 123,
 "created_at": "2026-01-01",
 "click_count": 1500
}

# Why SQL?
? ACID transactions
? Referential integrity
? Complex queries (analytics)

# Scaling: Sharding by short_code hash

# Cache-Aside Pattern with Redis

# Hot URLs (80/20 rule):
? 20% URLs get 80% traffic
? Cache these in Redis

# Cache Size:
? 20% of 182 TB = 36 TB
? Too much! Use LRU cache for hot URLs only
? Redis cluster: 100 GB RAM — ~20M hot URLs

# Flow:
1. Request comes for short URL
2. Check Redis cache
3. If HIT — Redirect immediately (< 1ms)
4. If MISS — Query DB — Cache in Redis — Redirect

# Cache Invalidation:
? On URL creation: No cache needed (new URL)
? On URL deletion: Remove from cache
? TTL: 24 hours (auto expire old entries)

# Production Architecture

 [CDN]
 ?
 [Load Balancer]
 ?
 [API Gateway + Rate Limiter]
 ?
 +---------------------------+
 — — ?
[URL Service] [Redirect Service] [Analytics Service]
 — — ?
[Key Gen Service] [Redis Cache] [Kafka Queue]
 — — ?
[Database Cluster] [Analytics DB]
(Primary + Replicas)

# Additional Components:
- Rate Limiter: 100 requests/min per user
- CDN: Cache redirects at edge
- Monitoring: Latency, error rates, throughput
- Alerting: DB connection pool, cache hit ratio

# Disaster Recovery:
- Multi-region deployment
- Database replication across regions
- Failover: Primary region down — Secondary takes over