Part 1 · 2 chapters · ~12 min

URL Shortener

A classic warm-up that still tests key generation, read-heavy caching, redirects and analytics without hot counters.

3

Brief, questions and numbers

the brief
  1. Users create short links for long URLs and anyone can follow them; owners see click counts.
questionanswer we assume
scale?100M new links/month, 10B redirects/month
custom aliases?yes, optional
expiry?optional per link
analytics latency?minutes is fine
consistency?a new link must work immediately for its creator
code
writes  = 100M / (30 × 86,400) ≈ 40/s average
reads   = 10B / (30 × 86,400) ≈ 3,900/s average, ~15,000/s peak
storage = 100M × 500 B ≈ 50 GB/month ≈ 600 GB/year
cache   = hot 20% of last month ≈ 10 GB in Redis
URL SHORTENER
write path generates a key; read path is a cached redirect
clientAPIPOST /links, GET /:keyRediskey → URLkey generatorrange per instancekey-value storekey → URL, owner, expiryanalyticsclick events → Kafka
swipe the figure sideways, or tap expand for full screen
1/5
write
POST /links stores a long URL under a new 7-character key. With base62, 62^7 ≈ 3.5 trillion keys.
new key, stored once62^7 ≈ 3.5 × 10^12 keys
4

v1, the break, and v2

v1. One service, one Postgres table (key primary key, url, owner, expires_at), random 7-character keys with a uniqueness check on insert, and redirects read straight from the database.

The break. At 15k redirects per second the database serves every read, and random keys need a retry loop on collision as the table fills. Click counting by UPDATE on each redirect creates hot rows for viral links.

v2. Leased id ranges with base62 encoding (no collisions), Redis read-through for redirects, click events to Kafka with an aggregation job, and a key-value store partitioned by key if the table outgrows one node.

the sentence
v2 buys almost unlimited redirect throughput and collision-free keys, and pays with eventually consistent click counts and a cache to keep warm.