Design a URL shortener, diagrammed

A URL shortener stores a long URL against a short key and redirects anyone who opens that key. In a system design interview the question tests three decisions: how you generate keys, how you keep redirects fast with a cache, and how you scale storage. A strong answer bounds the problem first, then defends each choice.

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. With a 100:1 read ratio that is about 120,000 reads per second on average, and peaks run higher. 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.

How long does the short key need to be?

Work it out instead of guessing. With base62 (digits plus upper and lower case letters), a 7-character key gives 62^7, which is about 3.5 trillion combinations. At 100 million new links a day you create roughly 36.5 billion a year, so seven characters last close to a century at that rate.

That arithmetic is worth saying out loud. It shows why six characters (about 57 billion) would run short within two years, and why seven is a defensible default.

A rough storage estimate

Assume about 500 bytes per record for the key, the long URL and a little metadata. At 100 million records a day that is about 50 GB a day, or roughly 18 TB a year before replication. The numbers are assumptions, and you should say so. What matters is that storage is large but simple, a single-key lookup, which is why a key-value store fits.

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. "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. "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. "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. "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.

More prompts of this kind are in system design interview questions.

Where to go next

• Practise this prompt on the System design surface described on the interview copilot page.
• Check the free daily minutes and paid tiers on the pricing page.
• Put the answer on a clock with System design mock interview under a clock.
• Learn why structure disappears under pressure in Why you freeze in interviews.