Design a URL shortener

Requirements. Functional: create a short link for a long URL; redirect a short link to the original; optionally custom aliases and expiry. Non-functional: redirects must be fast and highly available; the system is extremely read-heavy (each link is created once but clicked many times); codes should not be trivially guessable. Estimates: 100 million new links a month is ~40 writes per second; at 100:1 that is ~4,000 redirects per second. At ~500 bytes a link, five years is 100M × 60 months × 500 B ≈ 3 TB.

• API: POST /links {longUrl} returns {code}; GET /{code} responds with a redirect.
• Code space: base62 (0-9, a-z, A-Z) with 7 characters gives 62^7 ≈ 3.5 trillion codes - plenty.
• Generating codes: (1) hash the long URL and take 7 characters, checking for collisions; or (2) take a unique integer id and base62-encode it. To avoid a single counter, each app server reserves a block of ids (say 1,000 at a time) from a coordinator.
• Storage: a key-value lookup code → {longUrl, createdAt, expiresAt, ownerId} fits a key-value or wide-column store, or a sharded relational table. Hot codes are cached.

Base62 works like any other base: 125 is 2 × 62 + 1, so it encodes as 21. Seven characters give 62^7, or about 3.5 trillion codes.

Redirects: a 301 (permanent) lets browsers cache the redirect, which cuts load but hides repeat clicks from analytics. A 302 (temporary) sends every click through the service, which enables analytics. Deep dives interviewers like: handling hash collisions, preventing enumeration of sequential codes, blocking malicious URLs, expiring links, and recording click analytics asynchronously through a queue so redirects stay fast.