TLDR: Design a URL shortener like TinyURL or Bitly. This article now follows your system design interview template flow: use cases, requirements, estimations, design goals, HLD, and design deep dive.

TLDR: A URL shortener converts long links into compact aliases while serving extremely fast redirect reads at scale.

Twitter's early URL sharing created a real problem: long URLs broke tweet character limits and concealed link destinations from users. A URL shortener looks deceptively simple until you need to serve 100 million redirects per day with sub-10ms latency and guarantee zero short-code collisions under 10K writes per second — at that point a naive random string generator with a uniqueness check becomes a database bottleneck.

Understanding how to design a URL shortener teaches you core patterns shared by nearly every high-scale read-heavy system: ID generation strategies, cache-first redirect paths, database sharding, and the write amplification trade-off between counter-based and hash-based code generation.

By the end of this walkthrough you'll know why a base62-encoded auto-increment counter beats MD5 hashing (no collision detection loop required, shorter output codes), why a Redis redirect cache in front of your database is non-negotiable at 10K RPS (over 99% of traffic is reads, not writes), and why you'd shard the URL mapping table by hash(short_code) rather than creation timestamp to avoid hot partition accumulation.

📖 Use Cases

Actors

Use Cases

• Primary interview prompt: Design a URL shortener like TinyURL or Bitly.
• Core user journeys:
  • Create short link — POST a long URL; system generates a unique 6-char Base62 code and returns it
  • Redirect by code — GET /{shortCode} resolves to the original URL and issues a 301/302 redirect
  • Optional custom alias — creator specifies a preferred slug (e.g., bit.ly/launch-2025); system checks for collision
  • Expiry support — creator sets a TTL or hard expiry date; expired codes return 410 Gone
  • Click analytics — every redirect emits an async event capturing timestamp, referrer, IP geo-hash, and user-agent family
• Read and write paths are explained separately so bottlenecks and consistency boundaries are explicit.

This template starts with actors and use cases because architecture only makes sense when user behavior and workload shape are clear. In interviews, this section prevents random tool selection and keeps the answer grounded in business outcomes.

🔍 Functional Requirements

In Scope

• Short link creation — POST /shorten with long URL; returns short code with idempotency key support
• Redirect — GET /{shortCode} with cache-first lookup; sub-10ms p95 on cache hit
• Custom alias — optional user-defined slug with uniqueness validation
• Expiry — TTL-based and hard-date expiry; expired codes return 410 Gone
• Click analytics — async event per redirect (timestamp, referrer, geo-hash, device family)

Out of Scope (v1 boundary)

• Real-time analytics dashboards — async pipeline is built; UI is out of scope
• Full global active-active writes across every region
• A/B test link variants or personalized redirects
• QR code generation (can be a thin adapter on top of the short code)

Functional Breakdown

Initial building blocks:

• Code generation service — Redis INCR counter + Base62 encoding → guaranteed-unique 6-char codes
• Redirect API — stateless HTTP layer; cache-first lookup with DB fallback and write-through warm-up
• Metadata store — PostgreSQL table (short_code PK, long_url, created_at, expires_at, owner_id)
• Cache tier — Redis GET redirect:{code} → 99%+ hit rate on hot codes; TTL mirrors link expiry
• Async analytics pipeline — Kafka topic url.redirect.events → Flink consumer → ClickHouse aggregation

A strong answer names non-goals explicitly. Interviewers use this to judge prioritization quality and architectural maturity under time constraints.

⚙️ Non Functional Requirements

Non-functional requirements are where many designs fail in practice. Naming measurable targets and coupling architecture decisions to those targets is far more useful than listing technologies.

🧠 Deep Dive: Estimations and Design Goals

The Internals: Data Model

The primary table is url_mappings. Every short code — whether auto-generated or a custom alias — maps to exactly one long URL with optional expiry.

-- PostgreSQL schema; table is sharded by hash(short_code) % N
CREATE TABLE url_mappings (
    short_code   VARCHAR(12)  PRIMARY KEY,   -- 6 chars (auto) or up to 12 (alias)
    long_url     TEXT         NOT NULL,
    owner_id     UUID         NOT NULL,
    created_at   TIMESTAMPTZ  NOT NULL DEFAULT NOW(),
    expires_at   TIMESTAMPTZ,                -- NULL means no expiry
    deleted_at   TIMESTAMPTZ,                -- NULL means active; set on expiry/delete
    is_custom    BOOLEAN      NOT NULL DEFAULT FALSE
);

-- Expiry worker uses this index to batch-find expired codes efficiently
CREATE INDEX idx_expires ON url_mappings (expires_at)
    WHERE expires_at IS NOT NULL AND deleted_at IS NULL;

Why VARCHAR(12) and not VARCHAR(6)? Auto-generated codes are always 6 chars. Custom aliases can be up to 12. One column covers both without a separate table.

Redis key layout:

Why store expiresEpoch in the Redis value? The redirect service can check expiry without a DB round-trip: parse the epoch from the cached value, compare to System.currentTimeMillis(), and return 410 if expired — even on a cache hit.

Estimations

Assumptions for a Bitly-scale service:

Key insight: >99% of traffic is reads. The redirect cache hit ratio is the single most important operational metric — a 1% drop in hit rate at 115K RPS means 1,150 extra DB queries per second.

Design Goals

Performance Analysis

URL shortener health signals — the five metrics that matter most:

📊 High Level Design - Architecture for Functional Requirements

Building Blocks

Design the APIs

Create short link:

POST /shorten
Content-Type: application/json
Idempotency-Key: <uuid>

{
  "longUrl": "https://example.com/very/long/path?ref=campaign&utm_source=email",
  "alias": "launch-2025",        // optional custom slug
  "expiresAt": "2025-12-31T23:59:59Z"  // optional TTL
}

HTTP 201 Created
{
  "shortCode": "aB3kZ9",
  "shortUrl": "https://tiny.example.com/aB3kZ9",
  "expiresAt": "2025-12-31T23:59:59Z"
}

Redirect:

GET /aB3kZ9

HTTP 302 Found
Location: https://example.com/very/long/path?ref=campaign&utm_source=email

Click analytics:

GET /analytics/aB3kZ9?from=2025-01-01&to=2025-01-31

HTTP 200 OK
{
  "shortCode": "aB3kZ9",
  "totalClicks": 84201,
  "topReferrers": ["twitter.com", "email", "direct"],
  "topCountries": ["US", "IN", "GB"],
  "clicksPerDay": [{ "date": "2025-01-01", "count": 3120 }, ...]
}

Key design decisions:

• Idempotency-Key header on POST ensures safe retries without duplicate code creation
• 301 Permanent vs 302 Temporary redirect: use 302 so analytics can track future clicks (301 is cached by browsers and bypasses the shortener)
• Analytics API reads from ClickHouse (eventual), not PostgreSQL (strong) — latency vs freshness trade-off is explicit

Communication Between Components

Data Flow

Write path (create short link):

Client
  → POST /shorten
  → Shortener Service
      → Redis INCR url:counter        (atomic, globally unique ID)
      → Base62 encode(id)             (6-char short code)
      → PostgreSQL INSERT              (durable mapping)
      → Redis SET redirect:{code}     (write-through cache warm-up)
  ← 201 { shortCode, shortUrl }

Read path (redirect):

Client
  → GET /{shortCode}
  → Redirect Service
      → Redis GET redirect:{shortCode}    (cache hit: ~99% of requests)
          → 302 redirect immediately
      → PostgreSQL SELECT (cache miss only)
          → Redis SET (write-through)
          → 302 redirect
      → Kafka publish click event         (async, fire-and-forget)

Analytics path:

Kafka topic: url.redirect.events
  → Flink streaming job
      → Aggregate: clicks per code, referrer, geo
  → ClickHouse (columnar, append-optimised)
  → Analytics API (GET /analytics/{code})

flowchart TD
    A[Client] -->|POST /shorten| B[Shortener Service]
    B -->|INCR + Base62| C[Redis Counter]
    B -->|INSERT mapping| D[PostgreSQL]
    B -->|SET redirect:code| E[Redis Cache]
    B -->|201 shortCode| A

    F[Client] -->|GET shortCode| G[Redirect Service]
    G -->|GET redirect:code| E
    E -->|cache hit 99%| H[302 Redirect]
    G -->|cache miss| D
    D --> G
    G -->|fire-and-forget| I[Kafka]
    I --> J[Flink → ClickHouse]

🌍 Real-World Applications: API Mapping and Real-World Applications

This architecture pattern powers multiple production systems. Here is how each URL shortener feature maps to the design:

301 vs 302 — a decision that affects revenue: Twitter's t.co and Bitly both use 302 (temporary redirect) despite the permanent nature of most links. A 301 would be cached by browsers, bypassing the shortener entirely on repeat visits — which means zero analytics and zero ability to update the destination URL after creation. The performance cost of the extra hop is 10–50ms; the business value of every trackable click justifies it.

🔑 Feature Deep Dive: Custom Alias

A custom alias is a user-chosen slug (e.g., bit.ly/launch-2025) instead of the auto-generated 6-char code. The challenge is collision detection at write time without a race condition.

The naive approach fails: read-then-write has a race window where two callers check the same slug simultaneously, both see "available", and both succeed — overwriting each other.

The correct approach: use a database-level unique constraint and let the INSERT fail atomically:

public ShortenResult shorten(ShortenRequest req) {
    String shortCode;

    if (req.alias() != null) {
        shortCode = validateAlias(req.alias()); // length, charset check
    } else {
        Long id = redis.opsForValue().increment("counter:url_shortener");
        shortCode = base62Encode(id);
    }

    try {
        // PostgreSQL enforces uniqueness via PRIMARY KEY — no race condition possible
        database.save(new UrlMapping(shortCode, req.longUrl(), req.expiresAt(), req.alias() != null));
    } catch (DataIntegrityViolationException e) {
        // Alias was taken between our check and the insert — surface a clean 409
        throw new AliasTakenException(shortCode);
    }

    // Write-through cache warm-up
    String cacheValue = buildCacheValue(req.longUrl(), req.expiresAt());
    redis.opsForValue().set("redirect:" + shortCode, cacheValue, ttlFor(req.expiresAt()));

    if (req.alias() != null) {
        // Reserve alias flag for fast collision check on future creates
        redis.opsForValue().set("alias_reserved:" + shortCode, "1", ttlFor(req.expiresAt()));
    }

    return new ShortenResult(shortCode, buildShortUrl(shortCode));
}

Custom alias rules enforced at the API layer (before the DB hit):

• Length: 4–12 characters
• Charset: [A-Za-z0-9-_] only — no spaces, no special characters
• Blocklist: reserved slugs like api, analytics, admin, health are rejected with 422

---

⏰ Feature Deep Dive: Expiry Support

Expiry has two independent halves: serving expired codes correctly and cleaning up expired rows in the background.

Serving Expired Codes

The redirect service must detect expiry even on a cache hit — because the Redis TTL may not have fired yet due to lazy eviction. The solution is to embed the expiry epoch inside the cached value:

// Cache value format: "https://example.com/long/url|1735689600"
//                      long URL              | expires_at epoch (0 = no expiry)

public RedirectResult resolve(String shortCode) {
    String cached = redis.opsForValue().get("redirect:" + shortCode);

    if (cached != null) {
        String[] parts = cached.split("\\|", 2);
        String longUrl = parts[0];
        long expiresEpoch = parts.length > 1 ? Long.parseLong(parts[1]) : 0;

        if (expiresEpoch > 0 && Instant.now().getEpochSecond() > expiresEpoch) {
            // Code is cached but has expired — evict and return 410
            redis.delete("redirect:" + shortCode);
            throw new LinkExpiredException(shortCode);
        }
        return new RedirectResult(longUrl);
    }

    // Cache miss: check DB
    return database.findActive(shortCode)
        .map(m -> {
            redis.opsForValue().set("redirect:" + shortCode, buildCacheValue(m), ttlFor(m.expiresAt()));
            return new RedirectResult(m.longUrl());
        })
        .orElseThrow(() -> new ShortCodeNotFoundException(shortCode));
}

Background Expiry Worker

Redis TTL handles eviction from the cache layer automatically. PostgreSQL requires a background job to soft-delete expired rows:

-- Runs every 15 minutes via Spring Batch or a cron job
-- Processes in batches of 10K to avoid long-running transactions
UPDATE url_mappings
SET    deleted_at = NOW()
WHERE  expires_at < NOW()
  AND  deleted_at IS NULL
LIMIT  10000;

Why soft-delete instead of hard DELETE? Soft-delete preserves the row for audit trails, abuse investigations, and link-rot debugging. Hard DELETE runs after a 90-day grace period.

Expiry lifecycle summary:

Link created with expiresAt=T
  → PostgreSQL row: expires_at=T, deleted_at=NULL
  → Redis key: TTL set to (T - now) seconds

At time T:
  → Redis: may evict lazily (TTL fires) or on next access (active check)
  → PostgreSQL: still has expires_at=T, deleted_at=NULL (background worker hasn't run yet)

Redirect request arrives at T+5min (before worker runs):
  → Cache hit: epoch check detects expiry → 410, evict key
  → Cache miss: DB query finds row, expires_at < NOW() → 410

Background worker runs at T+15min:
  → Sets deleted_at=NOW() on all expired rows
  → Hard DELETE runs at T + 90 days

---

📈 Feature Deep Dive: Click Analytics Pipeline

Every redirect emits a lightweight event to Kafka. The analytics pipeline is intentionally decoupled from the redirect path — a Flink cluster failure should never affect redirect latency.

Kafka Event Schema

{
  "eventType": "url.redirect",
  "shortCode": "aB3kZ9",
  "timestamp": "2025-01-15T14:23:11.442Z",
  "referrer": "twitter.com",
  "userAgent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0)",
  "deviceFamily": "mobile",
  "countryCode": "US",
  "ipGeoHash": "9q8yy"
}

• ipGeoHash instead of raw IP: geo-hashed to cell-level (≈5km²) at the redirect service before emission — raw IPs never leave the request context.
• Topic partitioning key: shortCode — ensures all events for the same code land on the same Flink operator, enabling stateful aggregation without a shuffle.

Flink Aggregation Job

Kafka source (url.redirect.events)
  → KeyBy(shortCode)
  → TumblingWindow(1 minute)
  → Aggregate: clickCount, topReferrers (top-K), topCountries (top-K)
  → Sink → ClickHouse table: click_events_by_minute

ClickHouse: 
  CREATE TABLE click_events_by_minute (
      short_code    String,
      window_start  DateTime,
      click_count   UInt64,
      top_referrers Array(String),
      top_countries Array(String)
  ) ENGINE = MergeTree()
  PARTITION BY toYYYYMM(window_start)
  ORDER BY (short_code, window_start);

Why ClickHouse? It's a columnar OLAP store purpose-built for aggregation queries over append-only event data. A query like "total clicks for aB3kZ9 in January" scans only the click_count column for the matching short_code — not every column in every row.

⚖️ Trade-offs & Failure Modes (Design Deep Dive for Non Functional Requirements)

Scaling Strategy

Availability and Resilience

• Redirect Service is stateless — horizontal scale behind a load balancer; any pod can serve any request
• Redis failure fallback — if Redis is unreachable, fall back to PostgreSQL directly; accept latency degradation, not downtime
• PostgreSQL replication — synchronous replica for failover; read replicas for analytics queries (not the redirect path)
• Circuit breaker — wrap PostgreSQL calls with Resilience4j; open circuit after 5 consecutive failures; return 503 rather than hanging

Storage and Caching

Consistency, Security, and Monitoring

Consistency model by operation:

• Short code creation — strong consistency; PostgreSQL write must succeed before returning shortCode to caller
• Redirect resolution — eventual (Redis) to strong (PostgreSQL fallback); stale-while-revalidate acceptable for non-expired codes
• Click counts — eventual; Flink aggregation lag of 5–30 seconds is acceptable

Security:

• Rate-limit POST /shorten per API key (100 req/min) to prevent code-space exhaustion attacks
• Validate destination URLs against a phishing/malware blocklist on creation
• Encrypt owner_id in the mapping table; do not expose creator identity via the redirect path

Key SLO signals to monitor:

• redirect.cache_hit_ratio — alert if drops below 98%
• redirect.p95_latency_ms — alert if cache-hit p95 exceeds 15ms
• kafka.consumer_lag — alert if click event lag exceeds 60s
• postgres.connection_pool_utilization — alert above 70% to catch cold-miss storms early

🧭 Decision Guide

🧪 Practical Example for Interview Delivery

A repeatable way to deliver this design in interviews:

1. Start with actors, use cases, and scope boundaries.
2. State estimation assumptions (QPS, payload size, storage growth).
3. Draw HLD and explain each component responsibility.
4. Walk through one failure cascade and mitigation strategy.
5. Describe phase-based evolution for 10x traffic.

Question-specific practical note:

• Use cache-first redirects, write-through mapping, and background click aggregation to protect the primary database.

A concise closing sentence that works well: "I would launch with this minimal architecture, monitor p95 latency, error-budget burn, and queue lag, then scale the first saturated component before adding further complexity."

🏗️ Advanced Concepts for Production Evolution

When interviewers ask follow-up scaling questions, use a phased approach:

1. Stabilize critical path dependencies with better observability.
2. Increase throughput by isolating heavy side effects asynchronously.
3. Reduce hotspot pressure through key redesign and repartitioning.
4. Improve resilience using automated failover and tested runbooks.
5. Expand to multi-region only when latency, compliance, or reliability targets require it.

This framing demonstrates that architecture decisions are tied to measurable outcomes, not architecture fashion trends.

🛠️ Atomic INCR, Base62 Encoding, and Write-Through Cache: Three Decisions on One Critical Path

Three architectural decisions define the URL shortener's write and read paths:

1. Redis INCR for ID generation — atomic across all instances, no collision detection loop needed
2. Base62 encoding — converts the integer to a 6-character code (62⁶ ≈ 56 billion unique codes) rather than MD5, which requires a collision detection loop and produces longer outputs
3. Write-through cache warm-up — the first redirect request hits Redis, not PostgreSQL

// Write path: atomic counter → Base62 short code → DB persist → cache warm-up
public String shorten(String longUrl) {
    // INCR is atomic across all gateway instances — globally unique, no collision check
    Long id = redis.opsForValue().increment("url:shortener:counter");
    String shortCode = base62Encode(id);  // 62^6 ≈ 56B codes at 6 chars vs MD5's 32-char hash

    database.save(new UrlMapping(shortCode, longUrl, Instant.now()));

    // Write-through: warm cache immediately so the first redirect never touches the DB
    redis.opsForValue().set("redirect:" + shortCode, longUrl, Duration.ofDays(30));
    return shortCode;
}

// Read path: >99% of redirects exit at the Redis check; DB is the cold-miss fallback
public String resolve(String shortCode) {
    String cached = redis.opsForValue().get("redirect:" + shortCode);
    if (cached != null) return cached;

    return database.findByShortCode(shortCode)
        .map(m -> {
            redis.opsForValue().set("redirect:" + shortCode, m.longUrl(), Duration.ofDays(30));
            return m.longUrl();
        })
        .orElseThrow(() -> new ShortCodeNotFoundException(shortCode));
}

private String base62Encode(long id) { /* 0-9A-Za-z left-to-right encoding */ ... }

The INCR counter is why Base62 beats MD5 here: MD5 produces a random hash that must be checked for uniqueness on every write (a database round-trip), whereas a monotonically increasing counter is guaranteed unique by definition. Lettuce's non-blocking connection pool means the INCR call never blocks an application thread — at 100K RPS the event loop processes Redis responses asynchronously.

For a full deep-dive on Base62 ID generation strategies, counter sharding for write throughput, and cache-first redirect path optimisation, a dedicated follow-up post is planned.

📚 Lessons Learned

• Start with actors and use cases before drawing any diagram.
• Define in-scope and out-of-scope boundaries to prevent architecture sprawl.
• Convert NFRs into measurable SLO-style targets.
• Separate functional HLD from non-functional deep dive reasoning.
• Scale the first measured bottleneck, not the most visible component.

📌 TLDR: Summary & Key Takeaways

• Template-aligned answers are clearer, faster to evaluate, and easier to communicate.
• Good HLDs explain both request flow and state update flow.
• Non-functional architecture determines reliability under pressure.
• Phase-based evolution outperforms one-shot overengineering.
• Theory-linked reasoning improves consistency across different interview prompts.

📝 Practice Quiz

1. Why should system design answers begin with actors and use cases?

A) To avoid architecture work entirely
B) To anchor architecture decisions to workload and user behavior
C) To skip non-functional requirements

Correct Answer: B

1. Which section should define p95 and p99 targets?

A) Non Functional Requirements
B) Only the quiz section
C) Only the related posts section

Correct Answer: A

1. What is the primary benefit of separating synchronous and asynchronous paths?

A) It removes all consistency trade-offs
B) It isolates latency-critical user flows from heavy side effects
C) It eliminates monitoring needs

Correct Answer: B

1. Open-ended challenge: for this design, which component would you scale first at 10x traffic and which metric would you use to justify that decision?

🔗 Related Posts

• System Design Requirements and Constraints
• The Role of Data in Precise Capacity Estimations for System Design
• System Design: Caching and Asynchronism
• System Design Sharding Strategy
• System Design Replication and Failover