Design a URL shortener, diagrammed

"Design a URL shortener" is the system design question you are most likely to be asked, and the one candidates most often answer badly. Not because it is hard — because it is easy enough that people rush it, and the interviewer is really testing whether you can structure a conversation.

Here is the shape of a strong answer, and the order to say it in.

Start by bounding the problem

Before any boxes, get numbers. This takes ninety seconds and it changes every decision that follows.

• How many URLs created per day? Assume 100 million.
• Read-to-write ratio? Shorteners are read-heavy — call it 100:1.
• How long do links live? Assume forever unless told otherwise.
• Do we need custom aliases? Analytics? Expiry?

At 100 million writes per day you are at roughly 1,200 writes per second and 120,000 reads per second at peak. That read number is the whole design.

The core question: how do you generate the key?

Everything else in this problem is standard. The key generation is where interviewers actually probe, so lead with it.

Option 1 — hash the URL

Take MD5 or SHA-256 of the long URL, base62-encode it, take the first 7 characters. Simple, but collisions are real and you need a resolution strategy.

Option 2 — a counter

Increment a global counter and base62-encode it. No collisions ever, but the counter is a single point of contention, and sequential IDs leak how many links exist.

Option 3 — pre-generated key pool

Generate billions of keys offline, store them in a table, hand them out. Writes become a single fast read from the pool. This is usually the answer to reach for, and saying why is what separates a good answer from a passing one.

The architecture

With key generation settled, the rest falls out quickly: a write path that claims a key and stores the mapping, and a read path optimised hard for cache hits.

• Client → load balancer → application servers
• Key Generation Service handing out pre-generated keys
• Cache in front of the datastore, holding the hot set
• Key-value store for the mapping — the access pattern is a single-key lookup
• Async analytics pipeline so click tracking never blocks the redirect

That last point matters. If analytics writes are on the redirect path, your p99 is at the mercy of your analytics store.

Where they will push

1. 1

   "What happens when the cache misses?"

   You fall through to the store. With a 100:1 read ratio and a sensible eviction policy, the hot set is small and hit rates are high. Know your eviction policy — LRU is the usual answer.

2. 2

   "How do you handle a viral link?"

   A single key getting enormous traffic is a hot-key problem. Replicate that key across cache nodes, or push it to a CDN edge.

3. 3

   "How do you scale the database?"

   Shard by the short key itself. It is uniformly distributed by construction, which is one of the quiet advantages of the pre-generated pool.

4. 4

   "301 or 302?"

   A genuinely good question. 301 is permanent and gets cached by browsers — fewer requests hit you, but you lose click analytics. 302 keeps the analytics. Say which you would pick and why.

What a weak answer looks like

Weak answers jump straight to boxes, describe a database and a cache, and stop. They are not wrong, they are just indistinguishable from every other candidate that week.

The signal an interviewer is looking for is whether you can bound a problem, choose between options for stated reasons, and defend the choice when pushed. The diagram is how you keep that conversation organised — not the answer itself.