Design a URL Shortener (LLD): TinyURL System Design Step by Step

"Design a URL shortener, like TinyURL or Bitly."

It sounds like a five-minute idea — take a long URL, hand back a short one. But sit with it for a moment and questions pile up: how do you generate a code that's short and unique? What happens when two users' codes collide? Does the code need to be unguessable? What happens at a crore requests a day?

Let's work through this the way the last eight lessons taught you to — requirements first, classes second, patterns only where they earn their place.

Clarifying questions

Ask questions that would actually change the design — not filler questions:

• Should codes be sequential/predictable, or random and hard to guess?
• Do we need custom aliases (a user picks their own short code)?
• Do links expire?
• Roughly what scale — thousands a day, or millions?
• Do we need click analytics, or just redirect?

For this lesson, assume: random-looking codes are fine, no custom aliases for now, no expiry yet (we'll add it as an extension), and scale matters enough to think about collisions and distribution.

What objects do we need?

Reading the requirement ("shorten a URL, and later expand a code back to it") the way Lesson 1 taught — nouns first, then ask what job each one owns:

• URLShortener — the core service: shorten(longUrl) and expand(code).
• LinkGenerator — owns exactly one job: turn something into a short code.
• URLRepository — owns storing and looking up the (code → long URL) mapping. This is a data-access layer, kept separate from business logic (the "service → repository" layering mentioned back in Lesson 1's interview cues).

Generating short codes — more than one reasonable way

Here's the exact Strategy signal from Lesson 5: there is more than one reasonable way to generate a code, and the choice may need to change later (custom aliases, a premium tier, a different scheme entirely).

class LinkGenerator:
    def generate(self, long_url: str) -> str:
        raise NotImplementedError

BASE62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"

class CounterGenerator(LinkGenerator):
    def __init__(self):
        self._counter = 0

    def generate(self, long_url: str) -> str:
        self._counter += 1
        return self._to_base62(self._counter)

    def _to_base62(self, num: int) -> str:
        if num == 0:
            return BASE62[0]
        digits = []
        while num:
            digits.append(BASE62[num % 62])
            num //= 62
        return "".join(reversed(digits))

class HashGenerator(LinkGenerator):
    def generate(self, long_url: str) -> str:
        import hashlib
        digest = hashlib.md5(long_url.encode()).hexdigest()
        return digest[:7]   # truncated — must be checked for collisions

CounterGenerator (an incrementing number, base-62 encoded) gives short, guaranteed-unique codes with no collision checking needed — but codes are predictable and guessable in order. HashGenerator (hash the URL, truncate it) gives less-predictable codes, but now two different URLs can hash to the same short string, so the repository must detect and handle that collision (retry with a salt, or extend the code). Neither is "the correct one" — say the trade-off out loud and pick based on the requirements you clarified.

Putting it together

class URLRepository:
    def __init__(self):
        self._store = {}   # code -> long_url (a real system: a database)

    def save(self, code: str, long_url: str):
        self._store[code] = long_url

    def get(self, code: str) -> str | None:
        return self._store.get(code)

    def exists(self, code: str) -> bool:
        return code in self._store

class URLShortener:
    def __init__(self, generator: LinkGenerator, repo: URLRepository):
        self.generator = generator     # depends on the abstraction (DIP)
        self.repo = repo

    def shorten(self, long_url: str) -> str:
        code = self.generator.generate(long_url)
        while self.repo.exists(code):          # collision handling
            code = self.generator.generate(long_url + code)
        self.repo.save(code, long_url)
        return code

    def expand(self, code: str) -> str | None:
        return self.repo.get(code)

Notice URLShortener depends on the LinkGenerator abstraction, not a concrete class — exactly Dependency Inversion, so swapping CounterGenerator for HashGenerator means changing one line where URLShortener is constructed, nothing inside it.

Sequence: shorten and expand

Scaling: collisions and distribution

Two scale concerns worth naming, even without a full HLD discussion:

• Collisions: the while self.repo.exists(code) retry loop above handles them functionally, but at very high volume you'd rather avoid collisions altogether — which is exactly why CounterGenerator is often preferred at scale.
• Distributed counters: if URLShortener runs on many servers, a naive in-process counter on each server can generate duplicate codes. A common fix is pre-allocating counter ranges to each server (e.g. server A gets 1–1,000,000, server B gets 1,000,001–2,000,000), or using a centralized ID-generation service.

What if the interviewer changes this?

Common mistakes

• Hard-coding one generation scheme directly inside `URLShortener` instead of behind a `LinkGenerator` interface.
• Forgetting to handle hash collisions when using a hash-based generator.
• Ignoring the distributed-counter problem when asked about scale.
• Mixing storage/lookup logic directly into `URLShortener` instead of a separate `URLRepository`.

Quick recap

One thing to remember

"How do I generate the code" and "how do I store the mapping" are two different jobs — the moment you notice more than one reasonable way to do the first, that's a Strategy, not a hard-coded function.

Practice Zone

Five MCQs, then two reasoning questions.

Q1Clarifying questionseasy

Which clarifying question actually changes the design of a URL shortener, and is worth asking first?

Asked in

aWhat font should the landing page use?bShould short codes be predictable/sequential, or random? Do we need custom aliases?cWhat is the company's revenue model?dWhich cloud provider will host this?

Q2Code generationmedium

Why is base-62 encoding of an incrementing counter a common choice for generating short codes?

Asked in

aIt guarantees codes are impossible to guessbIt produces a short, unique string for every counter value with zero collision risk, since each number maps to exactly one codecIt requires a database join on every requestdIt only works for numbers under 100

Q3Hashing approachmedium

If you hash the long URL (e.g. MD5) and take the first 7 characters as the short code instead of using a counter, what new problem do you introduce?

Asked in

aNone — hashing is always collision-freebTwo different long URLs can hash to the same short code (a collision), which the design must now detect and handlecThe code becomes longer, not shorterdIt removes the need for a URLRepository entirely

Q4Strategy pattern heremedium

Why does a URL shortener's code-generation logic naturally fit the Strategy pattern from Lesson 5?

Asked in

aBecause it needs a SingletonbBecause there's more than one reasonable way to generate a code (counter-based, hash-based, random), and the choice should be swappable without touching the rest of the servicecBecause URLs are always the same lengthdBecause it requires an Adapter for legacy URLs

Q5Scalehard

At very high scale (millions of shortens per day, distributed servers), what breaks about a single in-process incrementing counter?

Asked in

aNothing, counters always scale infinitelybMultiple servers incrementing their own local counter can generate the same code — the counter itself needs to be centralised or partitioned (e.g. a distributed ID generator, or pre-allocated ranges per server)cBase-62 encoding stops working above 1000 requestsdThe URLRepository becomes a Singleton automatically

Think it through, then reveal:

FAQ

Next, the single most-asked LLD interview question — and the one where a "just add a class" plan falls apart fastest — Lesson 10: Design a Parking Lot →