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