Design a URL Shortener (TinyURL)
This is one of the most common system design interview questions. It seems simple but covers a surprisingly wide set of topics: hashing, databases, caching, and scalability.
Step 1: Clarify Requirements
Functional requirements:
- Given a long URL, generate a short URL (e.g.,
tiny.url/abc123) - Redirect users from short URL to original long URL
- Optional: Custom aliases, link expiration, analytics
Non-functional requirements:
- 100M short URLs created per day
- 10B redirects per day (100:1 read/write ratio — extremely read-heavy)
- Short URLs should be unique and hard to guess
- Redirect should be fast (< 10ms P99)
- System should be highly available (99.99% uptime)
Step 2: Estimate Scale
Writes: 100M URLs/day = ~1,200 writes/sec
Reads: 10B redirects/day = ~115,000 reads/sec
URL size:
- Long URL: ~2 KB average
- Short URL key: 7 characters = 7 bytes
- Metadata (user, timestamp, expiry): ~500 bytes
- Total per URL: ~2.5 KB
Storage for 10 years:
- 100M URLs/day × 365 × 10 × 2.5 KB ≈ 900 TB
(With replication: ~3 PB — need distributed storage)
Bandwidth:
- Write: 1,200 × 2.5 KB = 3 MB/sec
- Read: 115,000 × 500 bytes (just the redirect) = 57 MB/sec
Step 3: High-Level Design
┌──────────────────────────────────┐
│ Load Balancer │
└──────────────┬───────────────────┘
│
┌─────────────────┼─────── ──────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ URL │ │ URL │ │ URL │
│ Service │ │ Service │ │ Service │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
└─────────────────┼─────────────────┘
│
┌────────▼────────┐
│ Redis Cache │
│ (hot URLs) │
└────────┬─────────┘
│ cache miss
┌────────▼────────┐
│ Database │
│ (URL store) │
└─────────────────┘
API Design
POST /api/v1/shorten
Body: { longUrl: "https://...", customAlias?: "mylink", expiresAt?: "2025-12-31" }
Response: { shortUrl: "https://tiny.url/abc1234" }
GET /:shortCode
Response: 301/302 redirect to longUrl
DELETE /api/v1/:shortCode
Response: 200 OK
GET /api/v1/:shortCode/stats
Response: { clicks: 1234, createdAt: "...", ... }
301 vs 302 redirect:
301 Permanent— Browser caches the redirect; reduces server load but you can't update the destination302 Temporary— Browser always asks the server; allows analytics tracking and URL updates- For a URL shortener, 302 is usually preferred (lets you track clicks)
Step 4: Key Design Decisions
Generating Short Codes
You need a 7-character code from [a-zA-Z0-9] = 62 characters.
62^7 = ~3.5 trillion possible URLs — more than enough.
Option A: Hash + Encode (Recommended)
const crypto = require('crypto');
function generateShortCode(longUrl) {
// SHA-256 hash of the URL
const hash = crypto.createHash('sha256').update(longUrl).digest('hex');
// Take first 7 characters of base62-encoded hash
return base62Encode(hash).substring(0, 7);
}
function base62Encode(hex) {
const chars = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
let num = BigInt('0x' + hex);
let result = '';
while (num > 0) {
result = chars[Number(num % 62n)] + result;
num = num / 62n;
}
return result;
}
Problem: Hash collisions. Two different long URLs could produce the same 7-character code.
Solution: Check if the code exists in the DB. If it does, append a counter and rehash.
Option B: Counter + Encode
Maintain a global counter. Each URL gets the next counter value, encoded in base62.
Counter: 1000000
Base62: 4c92
Short code: 4c92
Problem: Single point of failure for the counter. Predictable codes (security risk).
Solution: Use distributed unique ID generation (Snowflake IDs).
Option C: Pre-generated Key Pool
Pre-generate millions of random 7-character codes offline, store them in a "Key DB." Service picks one when needed.
┌──────────────┐ ┌──────────────┐
│ Key │ fetch │ │
│ Generator │ ──────► │ Key DB │
│ (offline) │ │ (unused) │
└──────────────┘ └──────┬───────┘
│ assign
┌──────▼───────┐
│ URL DB │
│ (used) │
└──────────────┘
This is the cleanest approach for high-scale systems.
Database Design
-- URL table
CREATE TABLE urls (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
short_code VARCHAR(10) UNIQUE NOT NULL,
long_url TEXT NOT NULL,
user_id BIGINT,
expires_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW(),
click_count BIGINT DEFAULT 0
);
CREATE INDEX idx_short_code ON urls(short_code);
Database choice:
- Use a NoSQL key-value store (like Cassandra or DynamoDB) for the main URL table — the access pattern is a simple key lookup
- The key is
short_code, value islong_url + metadata - High write volume (1,200/sec) is handled well by Cassandra's write-optimized design
Caching Strategy
Since 80% of traffic goes to 20% of URLs (power law distribution), caching is extremely effective.
Cache design:
- Use Redis with LRU eviction policy
- Cache key:
short_code, value:long_url - Cache hit rate target: 95%+
- TTL: 24 hours (or match URL expiration)
Lookup flow:
1. Check Redis cache
→ Hit: Return long_url, 302 redirect (< 1ms)
→ Miss: Query database, cache result, redirect (< 10ms)
With 95% cache hit rate:
- 115,000 reads/sec × 0.95 = 109,250 served from cache
- 115,000 × 0.05 = 5,750 DB queries/sec (easily handled)
Handling Expiration
// When creating a URL
async function createShortUrl(longUrl, expiresAt) {
const shortCode = generateShortCode(longUrl);
await db.insert({
short_code: shortCode,
long_url: longUrl,
expires_at: expiresAt
});
if (expiresAt) {
// Set Redis TTL to match expiration
const ttlSeconds = (expiresAt - Date.now()) / 1000;
await redis.setex(shortCode, ttlSeconds, longUrl);
} else {
await redis.set(shortCode, longUrl);
}
return shortCode;
}
// When resolving a URL
async function resolveUrl(shortCode) {
// Check cache first
let longUrl = await redis.get(shortCode);
if (!longUrl) {
const record = await db.findOne({ short_code: shortCode });
if (!record || (record.expires_at && record.expires_at < new Date())) {
throw new Error('URL not found or expired');
}
longUrl = record.long_url;
await redis.set(shortCode, longUrl, { EX: 3600 });
}
// Track click asynchronously (don't block the redirect)
trackClick(shortCode).catch(console.error);
return longUrl;
}
Analytics (Bonus Deep Dive)
Track click analytics without impacting redirect latency:
[Redirect Service]
│ async
▼
[Kafka Topic: url_clicks]
│
▼
[Analytics Consumer]
│
▼
[ClickHouse / Data Warehouse]
Each click event:
{
"short_code": "abc1234",
"timestamp": "2024-01-15T10:30:00Z",
"ip_address": "1.2.3.4",
"user_agent": "Mozilla/5.0...",
"referer": "https://google.com"
}
Final Architecture
┌────────────────────────────────────────┐
│ DNS / CDN │
└────────────────┬───────────────────────┘
│
┌────────────────▼───────────────────────┐
│ Load Balancer │
│ (HAProxy / NGINX) │
└────────────────┬───────────────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
┌────────▼────────┐ ┌─────────▼────────┐ ┌─────────▼────────┐
│ URL Write │ │ URL Read │ │ URL Read │
│ Service │ │ Service │ │ Service │
└────────┬────────┘ └────────┬─────────┘ └────────┬─────────┘
│ │ │
│ ┌───────▼──────────────────────┐│
│ │ Redis Cluster (Cache) ││
│ └───────┬──────────────────────┘│
│ │ miss │
┌────────▼────────────────────▼────────────────────────▼────────┐
│ Cassandra Cluster │
│ (URL Key-Value Store) │
└────────────────────────────────────────────── ──────────────────┘
│
┌────────▼────────┐
│ Kafka │
│ (click events) │
└────────┬─────────┘
│
┌────────▼────────┐
│ ClickHouse │
│ (analytics) │
└─────────────────┘
Interview Follow-up Questions
Q: How would you handle 10× traffic growth?
Add more URL service instances behind the load balancer, expand the Redis cluster, and add Cassandra nodes. The system is horizontally scalable at every layer.
Q: How do you prevent abuse (spam/phishing)?
Add URL validation against a blocklist, rate limit by IP/user, and integrate with safe browsing APIs (Google Safe Browsing).
Q: How would you add custom domains?
Allow users to CNAME their domain to your service, store the domain in the URL record, and handle routing in the DNS layer.
Q: How do you handle the global distribution?
Deploy the read service in multiple regions (US, EU, Asia), replicate Cassandra across regions, and use anycast DNS to route users to the nearest datacenter.