System Design Interview: How to Design a URL Shortener Like Bit.ly

URL shortener is the most commonly asked system design question. It tests your ability to design for scale, handle edge cases, and make smart architectural trade-offs. Let's design one from scratch.

Step 1: Requirements

Functional Requirements

Given a long URL, generate a short URL

Redirecting a short URL takes the user to the original URL

Users can optionally set custom short URLs

URLs expire after a configurable time

Non-Functional Requirements

High availability (99.99% uptime)

Low latency (< 100ms for redirect)

Short URLs should not be predictable (security)

Scale: 100M new URLs per month, 10B redirects per month

Step 2: Capacity Estimation


Write: 100M URLs/month ≈ 40 URLs/second
Read:  10B redirects/month ≈ 4000 reads/second (100:1 read/write ratio)

Storage per URL: ~500 bytes (URL + metadata)
5-year storage: 100M × 12 × 5 × 500B = 3TB

Step 3: Short URL Generation

Approach: Base62 Encoding

Use characters: [a-z, A-Z, 0-9] = 62 characters

A 7-character short code gives us: 62^7 = 3.5 trillion unique URLs.

python
import hashlib
import base64

def generate_short_url(long_url: str, counter: int) -> str:
    # Combine URL with counter for uniqueness
    raw = f"{long_url}:{counter}"
    hash_bytes = hashlib.md5(raw.encode()).digest()
    # Take first 6 bytes and base62 encode
    encoded = base64.urlsafe_b64encode(hash_bytes[:6])
    return encoded.decode()[:7]

Alternative: Pre-generated Key Service

Generate millions of unique 7-character keys in advance and store them in a database. When a new URL is created, pop a key from the pool. This avoids collision entirely.

Step 4: Database Design

URL Table

sql
CREATE TABLE urls (
    short_code VARCHAR(7) PRIMARY KEY,
    original_url TEXT NOT NULL,
    user_id BIGINT,
    created_at TIMESTAMP DEFAULT NOW(),
    expires_at TIMESTAMP,
    click_count BIGINT DEFAULT 0
);

Database Choice: DynamoDB or Cassandra

Key-value lookups (short_code → original_url) are perfect for NoSQL

High write throughput with consistent read latency

Easy horizontal scaling

Step 5: High-Level Architecture


Client → Load Balancer → API Servers → Cache (Redis) → Database
                                            ↓
                                    Analytics Service → Kafka → Analytics DB

Read Path (Redirect)

User clicks short URL

Load balancer routes to API server

Check Redis cache for the mapping

If cache miss, query database

Return 301/302 redirect

Async: log click event to Kafka

Write Path (Create)

User submits long URL

Generate short code

Check for collision in database

Store mapping in database

Invalidate cache

Return short URL

Step 6: Caching Strategy

Redis with LRU eviction is perfect:


Cache hit ratio target: 80%
Cache size: 20% of 3TB = 600GB → distributed across nodes
TTL: 24 hours for popular URLs

Read: Redis GET → DB fallback → write-through cache
Write: Write to DB → invalidate cache

Step 7: Analytics

Track every redirect asynchronously:

json
{
  "short_code": "abc1234",
  "timestamp": "2025-01-15T10:30:00Z",
  "user_agent": "Mozilla/5.0...",
  "ip_address": "203.0.113.1",
  "referer": "https://twitter.com",
  "country": "IN"
}

Use Kafka for event streaming and ClickHouse for analytics queries.

Key Trade-offs to Discuss

Decision	Option A	Option B
Redirect code	301 (permanent, cached)	302 (temporary, trackable)
Hash function	MD5 (fast, collisions)	Counter-based (no collisions)
Database	SQL (consistency)	NoSQL (scale)
Cache	Write-through	Write-around

This design handles billions of URLs with sub-100ms latency. Practice drawing this architecture on a whiteboard — that's how you'll present it in an actual interview.

Blog AI Assistant