Hashing, base62 encoding, and the read-heavy path for a classic system design interview question.
URL shorteners show up in almost every system design round because they touch hashing, storage, caching, and read/write ratio — all in one small box.
The read-heavy path
Most traffic is a redirect: someone clicks intervues.club/x7k2 and you need a fast lookup. Writes (creating a short link) are rare compared to reads.
Encoding short codes
A common approach: auto-increment ID encoded in base62 (0-9, a-z, A-Z) for compact, URL-safe strings.
python
BASE62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"def encode(num: int) -> str: if num == 0: return BASE62[0] out = [] while num: num, rem = divmod(num, 62) out.append(BASE62[rem]) return "".join(reversed(out))def decode(code: str) -> int: return sum(BASE62.index(c) * (62 ** i) for i, c in enumerate(reversed(code)))
What to say in the room
Cache hot URLs — 80/20 on redirects; Redis in front of Postgres.
Collision strategy — pre-allocate IDs or use a dedicated ID service; don't rely on random hashes alone at scale.
Analytics async — log clicks to a queue; don't block the redirect path.
The interviewer isn't grading whether you drew the perfect diagram. They're grading whether you can name the bottleneck and trade read latency against write consistency.