URL Shortener System Design

The problem

A URL shortener looks too simple to produce a strong interview answer.

And that is exactly the point.

It is not the richest scenario in the world.

But it forces a skill interviews love to test:

seeing where the real difficulty actually is.

In a shortener, the hard part is usually not creating the link.

It is serving fast redirects at scale without turning every click into an expensive database hit.

Mental model

This system has two main operations:

1. shorten
2. redirect

Shorten is a write.

Redirect is a read.

In most realistic scenarios, reads dominate writes by a lot.

That changes the whole architecture.

If you want one clean summary:

The hot path in a URL shortener is usually GET /:shortId, not POST /urls.

Breaking the problem down

Align the requirements early

Before drawing anything, confirm:

• does the link expire or not?
• are custom aliases allowed or not?
• is real-time analytics required or not?
• does the redirect need to be extremely fast?

Those answers change the design quite a bit.

Choose the shortId strategy

There are a few classic options:

• sequential counter plus short encoding
• random identifier
• hash of the long URL with collision handling

Each one trades one pain for another.

A counter makes uniqueness easier, but may expose predictability.

A random ID reduces predictability, but requires collision control.

If the product allows custom aliases, you get another concern on top: name reservation, conflict, and abuse handling.

Make lookup and storage concrete

The main database needs to keep at least:

• shortId
• the long URL
• basic metadata

The dominant access on the hot path is lookup by shortId.

So that lookup needs to be direct and cheap.

Protect redirect with cache

Because the read path dominates, cache makes a lot of sense.

If one link becomes popular, caching shortId -> longUrl avoids hitting the database on every click.

Keep analytics out of the way

Counting clicks matters.

Slowing down redirect because of that is a mistake.

A healthy design usually looks like this:

• redirect fast
• record the click event off the main request path

If an analytics event gets lost once in a while, that is often acceptable.

If redirect fails, it is not.

Simple example

A mature answer might sound like this:

I will assume the main requirement is very fast redirects and that detailed analytics can be asynchronous. Creating short links happens much less often than redirecting them, so the architecture should revolve around the read path. For creation, I can generate a unique identifier, encode it in Base62, store the mapping in the database, and return the short URL. For redirect, I look up shortId and use cache for the most popular links. The click becomes an event outside the main request.

That already covers:

• read versus write ratio
• ID generation
• key lookup
• cache
• asynchronous analytics

Common mistakes

• Focusing too much on creation and forgetting the redirect path.
• Choosing an ID strategy without mentioning collisions or predictability.
• Putting analytics in the synchronous path.
• Ignoring expiration and customization when the prompt asks for them.
• Treating cache as optional without checking the read ratio.

How a senior thinks about it

Someone with more experience usually identifies the dominant flow early:

I want to create links simply, but the system lives or dies on redirect. So I design the read path first.

That kind of prioritization makes the answer much stronger.

It shows that you know where the real system cost lives.

In a scenario like this, confusing telemetry with the critical path is a very common mistake from people who still do not separate the main requirement from an important secondary one.

What the interviewer wants to see

In this scenario, the interviewer is checking whether you:

• separate creation from redirection
• notice that reads dominate writes
• think about short identifiers with criteria
• protect the hot path with cache and keep analytics out of it

A URL shortener looks small. That is exactly why it makes it obvious whether you can locate the real center of the architecture.

When you identify the hot path early, the rest of the design stops sounding like guesswork.