🔗 Design URL Shortener — System Design Interview Guide

Easy · Storage & Encoding

Design a service like bit.ly that converts long URLs into short, unique aliases and redirects users to the original URL when visited.

Open the interactive URL Shortener design on PrepGrind → Drag load balancers, caches, databases, and queues onto a canvas, run a live traffic simulation to watch latency and bottlenecks under load, and follow the full interview walkthrough below — free, in your browser.

Functional requirements

Given a long URL, generate a unique short code (e.g. bit.ly/abc1234)
Redirect any short URL to its original long URL
Optional: allow users to choose a custom alias
Optional: URLs can expire after a configurable TTL
Analytics: track click counts, referrers, and geo data

Non-functional requirements & scale

100M new URLs created per day (~1,200 writes/sec)
10B redirects per day (~115,000 reads/sec) — 100:1 read/write ratio
Redirect latency p99 < 10ms (cache-first)
Short codes must be globally unique and non-guessable
99.99% availability for the redirect path
5-year data retention = ~90 TB storage

Capacity estimation

Assume 100M URLs/day writes, 10B reads/day. Each URL record ~500 bytes. 5 years = ~90 TB. Short code: 7 chars from Base62 [0-9A-Za-z] = 62^7 ≈ 3.5 trillion unique codes. Read-heavy system; cache is critical.

Core entities

URL — shortCode (PK), longUrl, userId, createdAt, expiresAt, isCustom
User — userId, email, apiKey, plan (free/paid), rateLimitRemaining
Click — shortCode, timestamp, ipHash, country, referrer, userAgent

API design

POST /api/v1/urls — Create short URL. Body: { longUrl, customAlias?, ttlDays? }. Returns { shortUrl, shortCode, expiresAt }
GET /:code — Redirect to long URL. Returns HTTP 302. Fires async click event to Kafka.
GET /api/v1/urls/:code/stats — Returns click count, top referrers, geo breakdown.
DELETE /api/v1/urls/:code — Delete short URL (authenticated owner only).

High-level design

On create: generate Base62 short code from a Snowflake ID, write to Postgres + Redis. On redirect: Redis cache lookup (cache-aside) → DB fallback → publish click event to Kafka → 302 redirect. Analytics consumer writes to ClickHouse.

Deep dives

🔑 Short Code Generation

Option A: Hash (MD5) + take first 7 chars — risk of collisions under load. Option B: Auto-increment DB ID + Base62 encode — simple but single-point of failure. Option C: Snowflake ID (Twitter) + Base62 — distributed, monotonic, collision-free. Best choice is C. 62^7 gives 3.5 trillion codes; at 1,200/sec it takes ~90,000 years to exhaust.

⚡ Redirect at 115k RPS

Store active shortCode→longUrl mappings in Redis cluster. Cache hit = no DB query. 128GB Redis holds ~256M URLs (500 bytes each). LRU eviction; warm cache on startup. Use HTTP 302 (not 301) so browsers do not cache — ensures analytics fire on every visit.

📊 Analytics Pipeline

Synchronous analytics writes would add 50-100ms latency. Instead: publish click event to Kafka topic (fire-and-forget). Analytics consumer batch-writes to ClickHouse (columnar OLAP). Use Redis HyperLogLog for approximate unique visitor counts (12KB per key).

🌍 Global Scale

Deploy read replicas in each region. Use GeoDNS to route users to nearest region. Short code generation must stay globally unique — either use a central Snowflake ID service or assign node ID ranges per region (bits 10-19 of Snowflake = datacenter/machine ID).

Scaling considerations

Shard Redis by shortCode hash; use Redis Cluster for horizontal scale
Read replicas in Postgres; writes go to primary, reads from replicas
Rate limit by API key (token bucket) and by IP (leaky bucket)
Bloom filter to check custom alias availability in O(1) without DB hit
Separate hot-path (redirect) from cold-path (analytics) deployments

What interviewers expect by level

Junior: Describe the basic flow: POST to create short URL, store longUrl↔shortCode in DB, GET to redirect. Understand Base62 encoding.
Mid: Add Redis caching, discuss 301 vs 302, async analytics with Kafka, rate limiting, Snowflake ID generation.
Senior: Design for 10B redirects/day: sharded cache, DB replicas, geo-distribution, analytics pipeline, bloom filter for alias checks.
Staff: Multi-region active-active, eventual consistency trade-offs, cost tiers (hot/warm/cold storage), capacity planning, disaster recovery SLAs.

Practice more system design case studies

PrepGrind runs entirely in your browser, free, no installation required. Loading the interactive playground…