URL Shortener: Requirements & High-Level Design

Design a URL shortener like bit.ly: a service that takes a long URL and generates a shorter alias — a unique short link — and redirects users to the original URL when someone opens it. It should also track link usage, keeping click counts for every short link. The service must handle millions of URLs and high traffic, respond efficiently in near real-time, and keep every mapping persistent.

The next sections derive the design from this statement: its verbs become the functional requirements, its adjectives the non-functional ones, and its nouns the data model.

A URL shortener is a service that converts long, unwieldy URLs into compact aliases that redirect to the original destination. Services like bit.ly, TinyURL, and Twitter's t.co handle billions of redirects daily, turning links like https://example.com/products/category/electronics/item?id=12345&ref=campaign into something as short as https://short.ly/a1B2c3.

Behind the simplicity lies a system with interesting engineering constraints. The write path must generate a globally unique short code in milliseconds. The read path must resolve that code back to the original URL and issue an HTTP redirect with sub-10 ms latency — because redirects sit in the critical path of every click. And the analytics path must count billions of clicks without slowing down redirection.

The core engineering challenges are:

1. ID Generation — How do you produce short, unique identifiers across a distributed fleet of servers without coordination bottlenecks?
2. Encoding — How do you convert numeric IDs into compact, URL-safe strings? The character set and length determine how many URLs your system can represent.
3. Read-Heavy Scale — With a 100:1 read-to-write ratio and 100M read requests per day, the vast majority of traffic is redirects. Caching strategy dominates architecture decisions.
4. Consistency vs Availability — A newly created short URL must be resolvable globally within seconds. But cross-region replication introduces latency. How do you handle the window where a URL exists in one region but not another?

In this design, we'll build the system incrementally: first the core shortening and redirect flows, then analytics, then the deep dives into ID generation strategies, encoding trade-offs, caching architecture, and scaling via sharding.

LLD Connection: This problem connects to the Concurrent HashMap problem in Low-Level Design, where you implement the core data structure for O(1) key-value lookups. The URL shortener's in-memory cache and Base62 encoding both rely on hash-based access patterns.

We extract the core operations by analyzing the verbs in the problem statement:

• "takes a long URL and generates a shorter alias" → CREATE operation
• "redirects users to the original URL" → READ operation
• "track link usage" → UPDATE/INCREMENT operation

Each verb maps to a functional requirement:

FR1 — URL Shortening. Users submit a long URL and receive a unique, shortened alias. The short URL uses a compact format with English letters and digits (Base62: a-z, A-Z, 0-9) to save space and ensure uniqueness. The mapping between short and long URLs is permanent and immutable — once created, a short URL always points to the same destination.

FR2 — URL Redirection. When a visitor accesses a shortened URL, the service resolves the alias to the original URL and issues an HTTP redirect (302 Found) with minimal delay. The redirect must work from any geographic region.

FR3 — Click Analytics. The system tracks how many times each shortened URL is accessed. This counter is eventually consistent: it doesn't need to be exact in real time, and an occasional click event lost or replayed when a component crashes is acceptable, but counts must never be lost in bulk or drift.

Out of Scope

• Authentication and authorization — Who can create URLs or access analytics (handled by a separate auth service)
• URL expiration — TTL-based deletion of old URLs (can be added as a background job later)
• Custom aliases — User-chosen vanity URLs (short.ly/my-brand) add complexity to uniqueness guarantees
• Advanced analytics — Geographic tracking, device types, referrer analysis (beyond basic click count)
• Link preview / unfurling — OpenGraph metadata fetching for social media previews

We extract quality constraints from the adjectives in the problem statement:

• "unique" alias → System must guarantee no collisions
• "millions of URLs" + "high traffic" → System must handle large scale
• "efficiently" + "near real-time" → System must respond quickly
• "persistent" → System must not lose data

Traffic Estimation

Storage Estimation

ID Space Estimation

6-character Base62 provides 56.8 billion unique codes — 30× our 5-year requirement of 1.825 billion URLs. This leaves ample headroom for growth.

Bandwidth Estimation

The system is read-dominated and storage-modest — classic traits of a caching-friendly architecture.

The data model emerges from the nouns in the problem statement:

• "URL" and "alias" → URLMapping entity with short_url and original_url fields
• "link usage" and "click counts" → Analytics entity with click_count field
• "persistent" requirement → created_at timestamp for durability tracking

Ownership is distributed across services to enable independent scaling. The URL Shortening Service owns URLMapping (write-optimized). The Analytics Service owns Analytics (increment-optimized).

URL Mapping Table

The short_code is the primary key — every redirect performs a lookup by this field. Using it as the primary key ensures a single B-tree index serves both write (INSERT) and read (SELECT) paths.

Why is_active instead of DELETE? When malicious URLs are detected, we soft-delete by setting is_active = FALSE. This preserves the audit trail for abuse investigations and prevents the short code from being reassigned (which would break cached redirects).

Analytics Table

URLMapping and Analytics have a one-to-one relationship, and it is optional: a short URL gets its analytics row with the first flush after its first click, so a link that was never clicked has none.

The analytics table is separated from the mapping table to isolate the high-frequency increment path (every redirect) from the low-frequency write path (URL creation). Counter updates never lock or bloat the mapping rows that every redirect reads, and each table can be tuned for its own workload.

We derive API endpoints directly from the functional requirements (the verbs identified earlier):

• CREATE → POST /api/urls/shorten (accepts longUrl, returns shortUrl)
• READ → GET /{shortCode} (returns 302 redirect to original URL)
• UPDATE → Handled internally via event-driven architecture (not a public endpoint)

Shorten URL

POST /api/urls/shorten

Request Body:

{
  "longUrl": "https://example.com/very/long/path?param=value"
}

Response (201 Created):

{
  "shortUrl": "https://short.ly/a1B2c3",
  "shortCode": "a1B2c3",
  "createdAt": "2026-03-17T10:30:00Z"
}

Redirect

GET /{shortCode}

Response (302 Found):

HTTP/1.1 302 Found
Location: https://example.com/very/long/path?param=value
Cache-Control: no-store

Why 302 instead of 301? A 301 Moved Permanently tells browsers to cache the redirect indefinitely — subsequent visits bypass our server entirely. This breaks analytics (we can't count clicks we never see) and makes URL deactivation impossible (the browser never asks us again, so it never sees our 410 response). A 302 Found with Cache-Control: no-store ensures every click hits our server, enabling accurate counting and immediate deactivation.

Get Analytics (Internal)

GET /api/urls/{shortCode}/analytics

Response:

{
  "shortCode": "a1B2c3",
  "clickCount": 42583,
  "lastAccessed": "2026-03-17T15:22:00Z",
  "createdAt": "2026-01-15T08:00:00Z"
}

We build the architecture incrementally, adding components as each functional requirement demands them. This approach ensures every component exists for a reason — we're solving real problems, not drawing boxes for theoretical completeness.

1. URL Shortening (FR1)

Requirement: Users submit a long URL and receive a unique shortened alias.

The simplest architecture: a single service that generates an ID, encodes it as Base62, stores the mapping, and returns the short URL.

ID Generation: Each server is assigned a unique machine prefix (e.g., A, B, C). Within each server, an auto-incrementing sequence number generates IDs. The combination MachineID + SequenceNumber is globally unique without coordination.

Why this approach? Alternative approaches (hash functions, UUIDs, Snowflake IDs) either produce IDs that are too long or require coordination between servers. Machine ID + Sequence gives us:

• Short IDs — we control the length precisely
• No coordination — each server generates IDs independently
• Scalable — add more servers by assigning new machine prefixes

Base62 Encoding: The numeric ID is converted to a 6-character string using the 62 digits 0-9, A-Z, a-z, in that order:

With 6 characters, Base62 supports 62⁶ = 56.8 billion unique codes. At 1M URLs/day, that's enough for 155 years before exhaustion — far beyond our 5-year planning horizon.

2. URL Redirection (FR2)

Requirement: Clicking a short URL redirects to the original URL with minimal delay.

Redirects are the dominant traffic pattern — 100× more frequent than URL creation. A naive approach (query the database for every redirect) would require 1,160 QPS to the database. With a caching layer, we can serve the vast majority of redirects from memory.

Read-through caching: When the Redirect Handler receives a request, it asks the cache layer: a read-through cache library in front of Redis. On a cache miss, the library fetches the URL from the database, stores it in Redis, and returns it to the handler (Redis itself cannot query a database). The handler never talks to the database directly — the cache layer is its single read path.

Why read-through instead of cache-aside? With cache-aside, the application must implement cache-miss logic (check cache → miss → query DB → populate cache). With read-through, the cache library handles this transparently. The Redirect Handler's code is simply:

original_url = cache.get(short_code)  # Read-through: auto-fetches from DB on miss
if original_url:
    return redirect(original_url, status=302)
return not_found(404)

Cache sizing: With 100M reads/day and Zipfian distribution (20% of URLs get 80% of traffic), caching the top ~2M URLs serves about 93% of redirects (sized in the caching deep dive). At 500 bytes per entry: 2M × 500B = 1 GB — easily fits in a single Redis instance.

TTL strategy: Set TTL to 24 hours for most URLs. Short URLs that are accessed frequently will be refreshed by natural reads. URLs that go cold expire from cache automatically, freeing memory for active URLs.

3. Link Analytics (FR3)

Requirement: Track the number of times each shortened URL is accessed.

Analytics must not slow down redirects. The redirect path returns a 302 in < 10 ms. Analytics recording happens asynchronously after the redirect response is sent.

Two-tier counting:

1. Redis HINCRBY — For every click event it reads from the queue, the Analytics Worker runs HINCRBY clicks:pending {short_code} 1: an atomic O(1) increment in one Redis hash that handles any QPS. A link's live count is its database total plus its pending clicks in Redis.

2. Periodic DB flush — Every 60 seconds, a background job moves the pending clicks into the analytics table, exactly once even if it crashes halfway:

Why not increment the DB directly? At 1,160 QPS, direct UPDATE statements would generate 1,160 transactions/sec on the analytics table. With a 60-second flush, all clicks on the same link within that minute collapse into one row update, and the whole minute is written in a single transaction. Because clicks concentrate on popular links, far fewer rows are written than clicks received; the exact saving depends on how many distinct links are clicked each minute. The trade-off: the database total can be up to a minute behind, and a live count adds the pending clicks from Redis.

4. Complete Architecture

The architecture has three independent scaling paths:

Key property: The Redirect Handler is stateless — any instance can serve any redirect. This makes horizontal scaling trivial: add more instances behind the load balancer.

5. Sequence Diagrams

Sequence: Create Short URL

Sequence: Redirect (Cache Hit)