Topics
System Designmedium

Designing a URL Shortener

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.