Design a URL shortener

Clarify first: custom aliases? expiry? analytics? Then estimate: 100 M new URLs a month ≈ 40 writes/s; reads 100× that ≈ 4,000/s, peaks 10× — a read-heavy system where a single database would cope on writes and the redirect path needs a cache. Storage: 100 M × ~500 bytes ≈ 50 GB/year, fine for one primary. API: POST /urls {long_url, alias?, expires_at?} → {code} and GET /{code} → 302 Location: long_url. Data model: urls(code PK, long_url, owner_id, created_at, expires_at); the code is the primary key, so the redirect is one indexed lookup.

ID generation is the interesting decision. Hashing the URL and truncating collides (birthday problem at 7 chars of base62 ≈ 3.5 T space is fine for uniqueness, but two users shortening the same URL get the same code — decide if that is a feature) and needs a collision check. A counter encoded in base62 never collides and produces 7-char codes up to 3.5 T ids, but a single counter is a bottleneck and leaks volume; hand out ranges of 1,000 ids per app instance from the database, or use a random 7-char code with a unique index and retry on the rare conflict. Then evolve: put Redis in front of the redirect (hot codes are Zipfian: 20% of codes take 80% of reads), then read replicas, then a CDN edge for the redirect itself.