One of the most common system design questions, broken into the exact steps interviewers are actually listening for.
“Design a URL shortener” is one of the most common system design interview questions, precisely because it’s small enough to finish in 45 minutes but touches almost every core system design concept. Here’s a walkthrough of how to approach it, in the order an interviewer is actually listening for.
Start by asking clarifying questions, out loud
Before drawing a single box, state your assumptions and ask about scale: how many new links per day, how many clicks (reads) per day, and whether custom short links (like “/mybrand”) are needed.
This isn’t a stalling tactic — it shows you know that reads and writes need very different handling, and it’s usually the first thing interviewers are scoring.
The core flow is simpler than it looks
At its heart, the system does two things: given a long URL, generate a short code and store the mapping; given a short code, look up the long URL and redirect.
Say this out loud early — it grounds the rest of the conversation and stops the design from ballooning before the basics are agreed on.
How to actually generate the short code
Two common approaches come up: hash the long URL and take the first several characters, or keep an incrementing counter and convert it to a compact base-62 string (using letters and numbers instead of just digits).
The counter approach avoids hash collisions entirely and is usually the stronger answer, as long as you can explain how the counter stays unique across multiple servers — a range of IDs reserved by each server is the usual fix.
Reads vastly outnumber writes — design for that
Clicking a short link happens far more often than creating one, so the redirect lookup path is where performance matters most.
The strong answer here is a cache (like an in-memory key-value store) sitting in front of the database, so the vast majority of redirects never even touch the database. This is also the moment to mention a CDN or edge caching if links are accessed globally.
What strong “wrap up” answers look like
Strong candidates close by mentioning what they’d add given more time: analytics on click counts, link expiration, rate limiting to prevent abuse, and how they’d shard the database once a single instance can’t keep up.
You don’t need to build all of this in the interview — naming it shows you understand the system doesn’t stop at the happy path.