Question 5 · Track 2 · Store it and serve it

Design a URL shortener

Q: Design a URL shortener?

Base62-encode a hash into a short code. Store code → URL as one key and one value in a KV store. Handle collisions with a retry, or sidestep them with a monotonic counter. Serve the redirect — and that is the whole read path. A 301 is cached by the browser, so your click counter flatlines and you can never repoint the link. A 302 costs a request per click — and that request is the product.

The classic warm-up, and most candidates answer the wrong question.

Store it and serve it. 4 clarifying questions to ask first, the answer in 4 moves, the follow-up that catches a memorised answer and 3 supporting topics to watch or read.

Short answer live

What it is really testing

Not your hash function. The interviewer wants a data-store choice, defended.

Ask these first

Before a single box goes on the board. The answers change the design, which is the point of asking out loud.

How many links created per day, and how many clicks per link?
Do custom aliases have to work?
Do links expire?
Do we need click analytics, or just the redirect?

The answer, in 4 moves

In this order. Each move earns the next one — say them out loud rather than drawing all four and narrating afterwards.

1Base62-encode a hash into a short code.
2Store code → URL as one key and one value in a KV store.
3Handle collisions with a retry, or sidestep them with a monotonic counter.
4Serve the redirect — and that is the whole read path.

The trap

The follow-up that separates a rehearsed answer from a real one.

A 301 is cached by the browser, so your click counter flatlines and you can never repoint the link. A 302 costs a request per click — and that request is the product.

Watch or read

The pieces of this answer, each covered on its own. Take them whichever way suits you, then give the whole answer without looking.

Design a URL shortener, end to end

'Design a URL shortener' is the classic system-design warm-up, and most candidates answer the wrong question. The interviewer is not testing your hash function — they want a data-store choice, defended. Here is the whole answer in four moves: base62-encode a hash into a short code, store code → URL as one key and one value in a KV store, handle collisions with a retry or a monotonic counter, and serve the redirect. Then the follow-up that separates a rehearsed answer from a real one: a 301 is cached by the browser, so your click counter flatlines and you can never repoint the link. A 302 costs a request per click — and that request is the product.

Reel Read

HTTP caching: max-age and ETag

You fixed the CSS, deployed, and a customer sends a screenshot of last week's layout. Nothing is broken — the browser is obeying the header you sent it. Here is HTTP caching from first principles: why max-age is a promise you cannot take back, why no-cache does not mean don't cache, how ETag revalidation buys you a round trip with zero bytes, and why content-hashed filenames are the only invalidation strategy that actually works.

Reel Read

Hash tables explained in detail

You use a hash table every day and almost nobody can say what happens underneath. Built from scratch in about twenty lines of Python: the hash function, the bucket index, a real collision, chaining, the load factor, the resize — and where O(1) quietly stops being true.

Read

Part of System Design Interviews, Answered Out Loud. The fundamentals underneath it are the free CS course.