System design · application

Design: URL Shortener

A capstone walkthrough: shorten a long URL at write time, redirect it at read time — combining id generation, caching, sharding, and rate limiting into one read-heavy system.

🧩 Requirements

Two operations, wildly different traffic

POST /shorten
{ "url": "https://example.com/very/long/path" }
→ { "code": "b7" }

GET /b7
→ 302 Redirect
→ https://example.com/very/long/path

Read-heavy: redirects vastly outnumber creates (often 100:1 to 1000:1).
Low latency: a redirect should feel instant — nobody waits for a link.
Scalable: billions of links, ever-growing, ever-hotter subset.
Unique codes: no two URLs collide, without a global lock on every write.

🎯 Core challenge: mint unique codes fast on write, and serve lookups at massive scale and low latency on read — two very different jobs, one system.

✓ Big picture

The 10,000-ft view — trace a request left → right

Before the details: here's the whole system in one glance. Each box does one job; follow the numbers.

🏗️ Architecture

Split the write path from the read path

A Load Balancer routes both. Write mints a code from a shared counter and stores it. Read resolves a code — almost always via cache.

let counter = 0;

function shorten(url) {
  const id   = counter++;
  const code = toBase62(id);
  store.set(code, url);  // sharded
  return code;
}

Client

→

Write Svc

gen code

Read Svc

lookup

→

Cache

Redis

→

KV Store

sharded

Writes go straight to the store; the cache fills in lazily on the next read. See it live next →

▶️ See it live

Shorten a link, then visit it twice

First visit is a cache miss (falls through to the sharded store); a second visit is a cache hit — fast.

Client

→

Cache

Redis

→

KV Store

sharded

0 hits · 0 misses

Code → URL store (sharded)

Cache (Redis) — hot codes

✓ How it combines

Every piece maps to a pattern you already know

Base62 id-gen is a swappable Strategy — counter today, hash or Snowflake ids tomorrow, same interface.
The cache is a Proxy in front of the store — read-through caching, transparent to the caller.
Sharding & replication trade strict consistency for uptime — see CAP; AP is fine here.
Rate limiting on /shorten stops abuse from flooding the counter.
Analytics (clicks, geo) stream off the read path via pub/sub — never blocking the redirect.

🎯 Combines: Strategy (id-gen) + Proxy/caching + sharding + rate limiting + pub-sub analytics — a read-heavy system tuned for availability.

Back to all topics →