Introduction: The Humble Link That Scaled to Billions

Picture this: it’s 2002. You want to share a research paper over email. The URL is 180 characters long, wraps across three lines, and breaks when clicked. A student named Kevin Gilbertson had the same frustration — and TinyURL was born.

Fast forward to today. Bitly handles 10 billion clicks per month. Twitter’s t.co redirects every shared link in real time. What started as a convenience tool became one of the most quietly critical pieces of internet infrastructure.

Designing a URL shortener looks deceptively simple — “just store a short code mapping to a long URL” — but it touches nearly every hard problem in distributed systems: high-throughput reads, collision-free ID generation, cache stampedes, global latency, and abuse prevention at massive scale.

What Are We Building?

Functional Requirements

Non-Functional Requirements

Scale Estimation

Every distributed system design starts here. Architecture decisions are meaningless without understanding expected traffic patterns. Let’s work through the numbers explicitly.

Traffic Estimation:
  Writes/sec  = 10M / 86,400 ≈ 115 writes/sec
  Reads/sec   = 10B / 86,400 ≈ 115,000 reads/sec

Storage per record:
  Short code   7 bytes
  Long URL   150 bytes
  Metadata   100 bytes
  Total      260 bytes  →  2.6 GB/day  →  4.75 TB over 5 years

URL Namespace (Base62, 7 chars):
  62^7 = 3.5 trillion codes  →  lasts ~958 years at 10M/day

High-Level Architecture

The system splits into two fundamentally different paths: the write path (creating short URLs) and the read/redirect path (resolving them). Because reads outnumber writes 100 to 1, the entire architecture is optimized around the redirect path.

Redirect Path — Critical Hot Path

Every millisecond counts. Most traffic should be served from CDN or Redis — never touching the database.

Write Path — URL Creation

Database Design

PostgreSQL vs Cassandra

Schema Design

-- Core mapping table
CREATE TABLE url_mappings (
    short_code   VARCHAR(12)  PRIMARY KEY,
    long_url     TEXT         NOT NULL,
    user_id      BIGINT,
    created_at   TIMESTAMPTZ  DEFAULT NOW(),
    expires_at   TIMESTAMPTZ,
    is_active    BOOLEAN      DEFAULT TRUE,
    click_count  BIGINT       DEFAULT 0
);

-- Analytics events — partitioned by month for fast range scans
CREATE TABLE click_events (
    id           BIGSERIAL,
    short_code   VARCHAR(12)  NOT NULL,
    clicked_at   TIMESTAMPTZ  DEFAULT NOW(),
    ip_hash      VARCHAR(64),
    country_code CHAR(2),
    device_type  VARCHAR(20),
    referrer     TEXT,
    PRIMARY KEY (id, clicked_at)
) PARTITION BY RANGE (clicked_at);

-- Index for user dashboard queries
CREATE INDEX idx_url_user ON url_mappings(user_id, created_at DESC);

API Design

Create Short URL

POST /api/v1/urls
Authorization: Bearer <jwt_token>

{
  "long_url": "https://example.com/very/long/path",
  "custom_alias": "my-blog",       // optional
  "expires_at": "2026-01-01T00:00:00Z"  // optional
}

// 201 Created
{
  "short_url": "https://tny.io/aB3xKz",
  "short_code": "aB3xKz",
  "created_at": "2025-06-15T10:23:45Z"
}

// 409 Conflict — alias taken
{ "error": "ALIAS_TAKEN", "message": "The alias 'my-blog' is already in use." }

Redirect

GET /{short_code}

Response:
HTTP/1.1 302 Found
Location: https://example.com/very/long/path
Cache-Control: max-age=3600

Get Stats

GET /api/v1/urls/{short_code}/stats
Authorization: Bearer <jwt_token>

{
  "total_clicks": 14823,
  "unique_visitors": 11201,
  "top_countries": ["US", "IN", "GB", "DE"],
  "clicks_last_7_days": [...]
}

ID Generation: The Hardest Easy Problem

How do you generate a unique, collision-free short code at 115 writes/second across multiple API servers without coordination overhead? The answer is less obvious than it appears.

Snowflake ID Structure (64-bit)

Max throughput: 1,024 nodes × 4,096 IDs/ms = ~4 million IDs/millisecond
No central coordination required — each node generates IDs autonomously.

Caching Strategy

Caching is the single most important performance lever in this system. With a 100:1 read/write ratio, even a 95% cache hit rate means only 5,750 of 115,000 requests/second hit the database. Design the cache layers first.

Multi-Layer Cache Hierarchy

Redis Key Structure

Key:   "url:aB3xKz"
Value: "https://example.com/very/long/path"
TTL:   86400 seconds  (24h default — tiered by activity)

TTL Strategy

Message Queues and Analytics

Analytics must never block redirect responses. A redirect waiting for click persistence adds 50–200ms of latency to every single user request. The solution is complete decoupling via Kafka.

The redirect response is sent before the Kafka publish even begins. Why ClickHouse? Analytics queries like “clicks by country, last 30 days, grouped by hour” are columnar scan operations — ClickHouse performs these 10–100× faster than PostgreSQL on the same data volume.

Scalability Strategies

Microservices Decomposition

Database Sharding Strategy

When a single PostgreSQL instance can’t handle write volume (typically beyond ~10,000 writes/second), shard by consistent hashing on short_code. This produces even distribution and allows adding shards with minimal data migration — unlike prefix sharding which creates hot shards for popular prefixes.

Multi-Region Architecture

Deploy database clusters in at least 3 regions (US-East, EU-West, AP-Southeast). Use Anycast DNS to route users to their nearest region. URL creation can tolerate 50ms cross-region replication lag. Redirects always read from the local region’s replica — ensuring low latency regardless of where the URL was created.

Security Considerations

Rate Limiting — Sliding Window Counter

Key:   "ratelimit:write:{user_id}:{minute_bucket}"
Value: 47  (requests this window)
TTL:   60 seconds

If counter > limit  →  return 429 Too Many Requests + Retry-After header

Monitoring and Observability

Bottlenecks and Trade-offs

Real-World Technology Stack

The pattern is consistent across all major implementations: a fast KV lookup store, a distributed cache layer, and an async event pipeline for analytics. The specific technology varies; the architectural pattern is universal.

Interview Perspective

The URL shortener is a favorite interview question precisely because it looks simple and reveals how deeply a candidate thinks about distributed systems. Interviewers aren’t evaluating whether you know the “right answer” — they’re watching your reasoning process.

How to Structure Your 30-Minute Answer

Common Mistakes

Frequently Asked Questions

Conclusion

Designing a URL shortener well is a masterclass in distributed systems fundamentals. The problem is simple enough to understand in minutes but deep enough to reveal every weakness in how you think about scalability, consistency, and real-world engineering trade-offs.

When you’ve internalized this design, the same thinking applies directly to link-in-bio platforms, QR code generators, redirect managers for A/B testing, or any system with similar read-heavy, low-latency characteristics.