How to answer "design a URL shortener" as a PM

Walk the user's action through three pieces — a store that maps the short code to the long link, a way to make a unique short code, and the redirect that sends the click on. Then show you know reads vastly outnumber writes, so you'd add a cache, and name its cost: possible staleness. The interviewer isn't grading a perfect diagram. They're listening for whether you reason about tradeoffs out loud.

"Design a URL shortener" is the most common system-design warm-up a PM gets. It sounds like an engineering question, so people freeze reaching for engineering answers they don't have. You don't need them. The interviewer isn't asking you to build the thing — they want to see you take a product everyone uses, break it into parts, and talk about what each part costs. Here's how to walk it.

What does a URL shortener actually do?

Say the user action first — it shows you start from the user, not the architecture. Everyone already knows it: you paste a long link, get a short one, and clicking the short one sends you to the long one. There are really two actions in there, and keeping them separate is half the battle:

• Someone hands over a long link and gets a short one back. Once per link.
• Someone clicks the short link and gets sent to the long one. Over and over, every time anyone opens it.

Notice the imbalance: one link is created once but clicked thousands of times. Hold onto that — it's the insight the interviewer is waiting for.

What are the pieces, in plain words?

Three parts cover the whole product.

A store that maps short to long. A table: this short code points to that long link, so when a click comes in you look up the code and find where to send it. "Store" just means a place that remembers the pairing so it's still there tomorrow — a database. Its cost is speed: asking it the same question thousands of times a second gets expensive.

A way to make a unique short code. Every new link needs its own code — no two can share one, or clicks land in the wrong place. Something hands out a fresh short string nobody's used yet (a counter that never repeats, or random characters checked for collisions). You don't need to know how. What matters is that you can say why it has to be unique and what breaks if it isn't.

The redirect. When the click arrives, the system looks up the code and tells the browser "go here instead." It happens most often, so it's the one that has to be fast.

Trace a click through those three — arrives, code looked up, redirect sent — and you've answered the core of the question. Everything after is judgment.

Where's the tradeoff the interviewer is probing for?

This is where a good answer separates from a fine one. Come back to the imbalance: reads vastly outnumber writes. The system spends almost all its effort on lookups — asking the store the same question again and again.

The obvious move is a cache: a short-term memory of the popular links, kept close to where the clicks come in, so the system stops re-asking the store. Most clicks go to a small number of hot links, so a little memory absorbs most of the traffic.

Then name the cost, the part most people skip. A cache can go stale. If someone changes where a short link points, the cache may keep sending clicks to the old place until it catches up. That's a product decision, not a footnote: how wrong can a redirect be, and for how long? You decide that, not the engineer.

"I'd add a cache because reads dominate, and its cost is possible staleness" is the sentence that tells an interviewer you think in tradeoffs — worth more than any box you could draw. (This is an illustrative interview scenario, not a claim about any real company's setup. The point is the reasoning, not a blueprint.)

And when a detail stumps you — how the code is generated, how big the store gets — don't bluff. Ask a product question instead: how many clicks per link, and what does the user feel if a redirect is wrong? Interviewers would rather watch you reason toward an answer than recite one.

Where to practice this

Reading the walk-through gets you part of the way. Doing it gets you the rest — the tradeoffs only stick once you've placed the pieces yourself and defended each one.

That's what PMLabs is for. You get a problem like this one and a blank canvas, drag the boxes on, wire them together, and write one line on why each is there. A rubric scores it in about 30 seconds, so you find out what you missed while it's cheap to miss it. Sessions run about 15 minutes. No code.

One honest note: the scoring is AI against a rubric — a sparring partner, not an architecture review or a substitute for a qualified engineer. It won't guarantee you pass the interview. It gives you the reps, so you walk in reasoning out loud instead of freezing.

If you want to start, Module 1 is free, no card: pmlabs.app. And the cheat sheet covers the same pieces and tradeoffs on one page.

For the broader set of questions these warm-ups lead into, see the system design questions PMs actually get asked. And if the diagram itself trips you up, here's how to read an architecture diagram without knowing how to code.