Design a URL Shortener

Requirements

Functional: shorten a long URL to a short code; redirect a short code to its original URL; optional custom alias; optional click analytics. Non-functional: reads vastly outnumber writes (redirects happen far more often than new links are created); redirect latency should be low (cache-friendly); short codes must not collide.

Back-of-the-envelope

100M new short URLs/month ≈ 40 writes/sec average. If redirects outnumber creates by a 100-to-1 ratio, that's ~4,000 reads/sec average — the read path is what needs to scale, not the write path.

Architecture — write path vs. read path

The two paths have very different traffic profiles, so it's worth designing (and explaining in an interview) separately:

Key design decisions to discuss

• Short code generation: a distributed counter (Base62-encoded) guarantees uniqueness with no collision checks, but leaks the creation order/rate. A hash of the long URL (e.g. first 7 chars of MD5/SHA) is less predictable but needs a collision-check-and-retry loop.
• Custom aliases: just a separate uniqueness check against the same table before insert.
• Redirect type: a 301 (permanent) redirect lets browsers cache it, reducing load further but making click analytics harder to capture; a 302 (temporary) always hits your server, giving accurate analytics at the cost of more traffic.
• Database choice: the access pattern (single-key lookup by short_code) fits a key-value store or a simple indexed SQL table equally well — this is a case where "NoSQL vs SQL" isn't the interesting question; caching strategy is.

Follow-ups interviewers often ask

• How would you handle click analytics without slowing down the redirect path? (Answer: log asynchronously — fire-and-forget to a queue, don't block the redirect on a write.)
• How do you prevent someone from enumerating all short codes? (Answer: don't use a predictable sequential counter directly as the public code; encode/obfuscate it.)