URL Shortener (TinyURL)

Overview

The URL Shortener (TinyURL-style) system design is a classic interview question that tests your understanding of distributed systems fundamentals. Companies like Google, Amazon, and Meta frequently ask this because it elegantly combines hashing, database design, scalability, and trade-off discussions into a single problem. Understanding how to convert long URLs into short codes, handle collisions, and scale to billions of redirects demonstrates real-world systems thinking. This design matters in interviews because it's approachable yet reveals whether you can reason about high-throughput read-heavy workloads, idempotency, and the trade-offs between different encoding strategies (base62, UUID, etc.).

Requirements

Functional

Generate a unique short code for any given long URL
Redirect users from short URL to original long URL
Support custom short URLs (optional vanity URLs)
Track click analytics (number of redirects per short URL)
Support URL expiration (optional TTL)
Handle duplicate URLs (same long URL may get same or different short code based on design)

Non-Functional

High availability — redirects must work 99.99% of the time
Low latency — redirect should complete in under 100ms
Scalability — support billions of URLs and millions of redirects per second
Durability — no data loss; short codes must persist
Short code length — typically 6–8 characters for readability

Capacity Estimation

Assume 100M new URLs/month, 10:1 read-to-write ratio (1B redirects/month). Storage: ~500 bytes per URL record → ~50GB/month. Peak redirect QPS: ~30K.

Architecture Diagram

Component Deep Dive

API Gateway

Entry point for all requests. Routes create and redirect traffic, applies rate limiting, and handles SSL termination.

Shortening Service

Generates short codes from long URLs. Uses base62 encoding of a unique ID (from ID generator) or hash-based approach with collision handling.

ID Generator

Produces globally unique IDs (e.g., Snowflake, UUID, or database sequence). Ensures no two short codes collide across distributed nodes.

Redirect Service

Resolves short code to long URL. Heavily cache-optimized; most traffic hits cache. Returns 301 (permanent) or 302 (temporary) redirect.

Database

Stores mapping of short_code → long_url, metadata, created_at. Sharded by short_code. Use Cassandra or DynamoDB for write scalability.

Cache Layer

Redis or Memcached for hot short_code → long_url lookups. Reduces database load; 99%+ of redirects served from cache.

Database Design

Use a distributed key-value store (Cassandra, DynamoDB) with short_code as partition key. Schema: short_code (PK), long_url, user_id, created_at, expires_at, click_count. Index long_url for deduplication if needed. Consider separate analytics DB for click tracking.

API Design

Method	Path	Description
`POST`	/api/v1/shorten	Create short URL. Body: {long_url, custom_code?}. Returns short URL.
`GET`	/{short_code}	Redirect to original URL. Returns 301/302 with Location header.
`GET`	/api/v1/analytics/{short_code}	Get click count and analytics for a short URL.
`DELETE`	/api/v1/{short_code}	Delete a short URL (soft delete with TTL).

Scalability & Trade-offs

Base62 ID vs Hash: ID guarantees uniqueness and shorter codes; hash allows stateless generation but needs collision handling.
301 vs 302 redirect: 301 improves cacheability and reduces server load; 302 allows tracking and analytics at redirect service.
Read vs write scaling: Redirects are read-heavy — cache aggressively. Shortening is write-heavy — use async writes and batch inserts.

Related System Designs

Infrastructure