URL shortening is far more than a convenience feature. At the scale of services like bit.ly (processing over 600 million link clicks per month), TinyURL (one of the oldest shorteners still in operation), and Twitter's t.co (which wraps every URL shared on the platform for analytics and safety scanning), URL shorteners are critical infrastructure that sits in the hot path of billions of HTTP requests daily.

The core value proposition is deceptively simple: given a long URL like https://example.com/products/category/electronics/item/12345?utm_source=newsletter&utm_medium=email, produce a short alias like https://short.ly/a7Bx3q that redirects to the original. But beneath this simplicity lies a rich set of engineering challenges that make this one of the most popular system design interview questions.

Real-world URL shorteners serve several critical functions beyond just making links shorter. Twitter's t.co service wraps every outbound URL to scan for malware, track engagement metrics, and provide a consistent character count for tweets. Marketing platforms like bit.ly and Rebrandly provide detailed click analytics — geographic distribution, device types, referral sources, and time-of-day patterns — that drive campaign optimization decisions worth millions of dollars.

Understanding the scale is critical because it drives every architectural decision downstream. A URL shortener serving 1,000 requests per day can run on a single SQLite database. One serving 100 million redirects per day requires distributed caching, database sharding, CDN integration, and carefully designed data pipelines. The interview question is specifically testing whether you can navigate these scaling thresholds and explain which architectural components become necessary at each stage.

Before drawing any architecture diagrams, a strong system design answer begins with requirements gathering. This phase establishes the scope of the problem and surfaces the constraints that drive every subsequent decision. Interviewers specifically look for candidates who ask clarifying questions rather than immediately jumping into a solution.

A critical question to ask the interviewer: should short URLs be permanent or expire by default? This decision profoundly affects storage growth, garbage collection strategy, and cache TTL policy. If URLs are permanent, storage grows without bound and you need a plan for 90+ TB of data. If URLs expire after, say, 5 years, you can reclaim short codes and keep storage manageable.

The heart of a URL shortener is the algorithm that converts a long URL into a short, unique code. There are three primary approaches, each with distinct trade-offs around collision risk, predictability, performance, and implementation complexity. A strong interview answer compares all three and justifies a choice based on the specific requirements.

For the remainder of this design, we will assume the Snowflake counter approach: a distributed ID generator produces unique 64-bit IDs, which are encoded in Base62 to produce 7-character short codes. This eliminates collision handling complexity and supports distributed writes across multiple data centers.

The URL mapping table is the core data structure of the entire system. Every redirect must look up this table (or its cache), so the schema and storage engine choice directly impact latency, throughput, and operational complexity. The read-to-write ratio of 100:1 means we must optimize aggressively for reads while maintaining acceptable write performance.

The SQL vs NoSQL decision depends on your scale tier and consistency requirements. For a URL shortener, the access pattern is extremely simple: point lookups by short_code for reads, and single-row inserts for writes. There are no complex joins, no multi-table transactions, and no range queries on the critical path. This access pattern is ideal for both SQL and NoSQL databases.

graph TB
    subgraph "Database Sharding by short_code Hash"
        Client["API Server"] --> Router["Shard Router<br/>hash(short_code) % N"]
        Router --> S0["Shard 0<br/>codes a-j<br/>hash range 0-24%"]
        Router --> S1["Shard 1<br/>codes k-r<br/>hash range 25-49%"]
        Router --> S2["Shard 2<br/>codes s-z<br/>hash range 50-74%"]
        Router --> S3["Shard 3<br/>codes A-Z, 0-9<br/>hash range 75-99%"]
    end

    S0 --> R0["Read Replica 0a"]
    S0 --> R1["Read Replica 0b"]
    S1 --> R2["Read Replica 1a"]
    S1 --> R3["Read Replica 1b"]

    style Router fill:#f59e0b,stroke:#333,color:#fff
    style S0 fill:#3b82f6,stroke:#333,color:#fff
    style S1 fill:#3b82f6,stroke:#333,color:#fff
    style S2 fill:#3b82f6,stroke:#333,color:#fff
    style S3 fill:#3b82f6,stroke:#333,color:#fff

For the write path, the database only needs to handle ~6,000 writes per second at peak. This is well within the capacity of a single PostgreSQL primary or a small DynamoDB table. The real scaling challenge is on the read path, which is why the caching layer (covered in a later section) is the most critical architectural component.

The architecture of a URL shortener has two distinct paths: the write path (creating short URLs) and the read path (redirecting). The read path is 100x hotter and must be optimized for absolute minimum latency. The write path has more flexibility but must guarantee uniqueness and durability. Understanding these two paths separately is the key to a clean design.

graph TB
    subgraph "Write Path — URL Creation"
        U1["Client / API Consumer"] -->|"POST /api/v1/urls"| LB1["Load Balancer<br/>L7 / ALB"]
        LB1 --> API1["API Server 1"]
        LB1 --> API2["API Server 2"]
        LB1 --> API3["API Server N"]
        API1 --> IDG["ID Generator<br/>Snowflake Service"]
        API1 --> DB["Primary Database<br/>Write Master"]
        API1 --> Cache1["Redis — Write-Through<br/>Cache new mapping"]
    end

    subgraph "Read Path — Redirect"
        U2["Browser / Client"] -->|"GET /a7Bx3q"| CDN["CDN Edge<br/>(301 cached)"]
        CDN -->|"Cache MISS"| LB2["Load Balancer"]
        LB2 --> RS1["Redirect Server 1"]
        LB2 --> RS2["Redirect Server N"]
        RS1 --> Cache2["Redis Cluster<br/>Cache-Aside Lookup"]
        Cache2 -->|"Cache MISS"| DBR["Database<br/>Read Replica"]
    end

    style CDN fill:#10b981,stroke:#333,color:#fff
    style Cache1 fill:#ef4444,stroke:#333,color:#fff
    style Cache2 fill:#ef4444,stroke:#333,color:#fff
    style DB fill:#3b82f6,stroke:#333,color:#fff
    style DBR fill:#3b82f6,stroke:#333,color:#fff
    style IDG fill:#8b5cf6,stroke:#333,color:#fff

The stateless design of both API servers and redirect servers means horizontal scaling is straightforward: add more instances behind the load balancer. The ID generator is either embedded (each API server has its own Snowflake machine ID) or a lightweight separate service. The only stateful components are the database and Redis, both of which have well-understood scaling patterns (sharding for the database, clustering for Redis).

The redirect HTTP status code is the single most consequential design decision in a URL shortener, yet many candidates gloss over it. The choice between 301 (Moved Permanently) and 302 (Found / Temporary Redirect) has profound implications for caching behavior, SEO juice transfer, analytics accuracy, and infrastructure costs. Understanding this trade-off separates senior engineers from juniors in interviews.

sequenceDiagram
    participant B as Browser
    participant C as CDN Edge
    participant S as Redirect Server
    participant R as Redis Cache
    participant D as Database

    Note over B,D: First Click (301 or 302 - same flow)
    B->>C: GET /a7Bx3q
    C->>S: Cache MISS - forward to origin
    S->>R: GET short:a7Bx3q
    R-->>S: https://example.com/long-url
    S-->>C: 301 Location: https://example.com/long-url
    C-->>B: 301 Location: https://example.com/long-url
    Note over B: Browser follows redirect

    Note over B,D: Subsequent Clicks with 301
    B->>B: Cached! Redirect directly
    Note over B: Never contacts server again

    Note over B,D: Subsequent Clicks with 302
    B->>C: GET /a7Bx3q (every time)
    C->>S: Forward to origin (every time)
    S->>R: GET short:a7Bx3q
    R-->>S: https://example.com/long-url
    S-->>C: 302 Location: https://example.com/long-url
    C-->>B: 302 Location: https://example.com/long-url

In practice, the redirect server does very little work: it receives the request, extracts the short code from the URL path, checks Redis for the mapping, returns a 301 or 302 with the Location header, and optionally fires an async analytics event. The entire operation takes 1-5ms when the cache is hit. This simplicity is why a single redirect server can handle 50,000+ requests per second — the response is just a tiny HTTP header with no body.

Caching is the most impactful optimization in a URL shortener. The read path handles 100x more traffic than the write path, and URL mappings are immutable once created (the short code always maps to the same long URL). This makes URL shorteners an ideal caching workload: high read volume, small record sizes, and virtually no cache invalidation needed. A well-tuned Redis cache can absorb 95%+ of all redirect traffic, reducing database load by 20x.

Analytics and rate limiting are the two supporting pillars that transform a simple redirect service into a production-grade platform. Analytics provide the business value that justifies the service (click data drives marketing decisions), while rate limiting protects the system from abuse. Both must be implemented without adding latency to the critical redirect path.

graph LR
    subgraph "Redirect Hot Path (< 5ms)"
        RS["Redirect Server"] -->|"1. Lookup"| Redis["Redis Cache"]
        RS -->|"2. Return 302"| Client["Client"]
    end

    subgraph "Analytics Cold Path (async)"
        RS -->|"3. Fire & forget"| Kafka["Kafka Topic<br/>click-events"]
        Kafka --> Consumer["Analytics Consumer"]
        Consumer --> ClickDB["ClickHouse / TimescaleDB<br/>Click Analytics Store"]
        Consumer --> GeoIP["GeoIP Enrichment"]
        Consumer --> Agg["Real-time Aggregator<br/>Flink / Spark Streaming"]
        Agg --> Dashboard["Analytics Dashboard<br/>Redis counters + time-series"]
    end

    style RS fill:#3b82f6,stroke:#333,color:#fff
    style Redis fill:#ef4444,stroke:#333,color:#fff
    style Kafka fill:#f59e0b,stroke:#333,color:#fff
    style ClickDB fill:#10b981,stroke:#333,color:#fff

Rate limiting protects the system from three types of abuse: creation spam (bots creating millions of URLs to host phishing or malware links), redirect abuse (DDoS attacks against the redirect infrastructure), and analytics pollution (fake clicks to inflate or manipulate analytics data). Each requires a different rate limiting strategy.

The analytics pipeline should also detect and flag suspicious patterns: sudden spikes in creation volume from a single API key (potential spam campaign), URLs whose destinations appear on phishing blocklists, and click patterns that resemble bot traffic (identical User-Agent strings, evenly-spaced timestamps, sequential IP addresses). These signals feed into an abuse detection system that can automatically quarantine suspicious URLs.

At the scale of billions of URLs and tens of billions of monthly redirects, every component of the system faces unique scaling challenges. The strategies that work at millions of URLs (single database, single Redis instance, single data center) break down and must be replaced with distributed alternatives. This section covers the four critical scaling dimensions: database sharding, global distribution, TTL and garbage collection, and operational considerations for extreme scale.

graph TB
    subgraph "Global Distribution"
        DNS["GeoDNS<br/>Route to nearest region"] --> US["US-East Region"]
        DNS --> EU["EU-West Region"]
        DNS --> AP["AP-Southeast Region"]

        subgraph US["US-East (Primary)"]
            US_LB["LB"] --> US_RS["Redirect Servers"]
            US_RS --> US_Redis["Redis Cluster"]
            US_Redis --> US_DB["Primary DB<br/>(writes + reads)"]
        end

        subgraph EU["EU-West"]
            EU_LB["LB"] --> EU_RS["Redirect Servers"]
            EU_RS --> EU_Redis["Redis Cluster"]
            EU_Redis --> EU_DB["Read Replica"]
        end

        subgraph AP["AP-Southeast"]
            AP_LB["LB"] --> AP_RS["Redirect Servers"]
            AP_RS --> AP_Redis["Redis Cluster"]
            AP_Redis --> AP_DB["Read Replica"]
        end

        US_DB -.->|"Async replication"| EU_DB
        US_DB -.->|"Async replication"| AP_DB
    end

    style DNS fill:#f59e0b,stroke:#333,color:#fff
    style US_Redis fill:#ef4444,stroke:#333,color:#fff
    style EU_Redis fill:#ef4444,stroke:#333,color:#fff
    style AP_Redis fill:#ef4444,stroke:#333,color:#fff
    style US_DB fill:#3b82f6,stroke:#333,color:#fff

TTL and garbage collection become critical at billion-URL scale. Without expiration, the database grows by 18 TB per year and eventually becomes unmanageable. Even with sharding, each shard accumulates data that may never be accessed again. A garbage collection strategy is essential for long-term operational health.

The final scaling consideration is operational: how do you perform database migrations, schema changes, and infrastructure upgrades without downtime on a system that handles billions of redirects? The answer is blue-green deployments for application servers, online schema changes (pt-online-schema-change for MySQL, pg_repack for PostgreSQL) for the database, and feature flags for gradual rollout of new redirect logic. Never perform a stop-the-world migration on a URL shortener — every minute of downtime breaks millions of links across the internet.