A URL shortener sounds trivial precisely because the shortening algorithm is the boring part. The frontend prompt is really about three smaller, genuinely interesting decisions: instant feedback, how to paginate a list that barely changes, and how stale analytics are allowed to be.
12 min read
Check your understanding
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 3
Why does optimistic feedback make sense for submitting a URL to be shortened?
Stuck? Ask the AI tutor
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Interview questions on Designing a URL Shortener's Frontend
What interviewers actually ask about this, and what a strong answer has to cover.
Design the frontend for a URL-shortening service. Walk me through the core submission flow, the user's links dashboard, and how you'd handle click analytics for each link.
A strong answer covers
Proposes optimistic feedback on submit with copy-to-clipboard as the core interaction, explaining why the low-stakes, reliable nature of the action justifies it
Chooses offset-based pagination for the links dashboard and explains why, contrasting it with a feed's cursor-based needs
Proposes a generous staleness tolerance for click-count analytics with reasoning about why real-time accuracy isn't needed
Keeps the shortening algorithm itself out of scope as a backend concern, staying focused on the frontend decisions
Likely follow-ups
A user reports their links dashboard shows a link twice after they refresh mid-pagination. How would offset pagination cause that, and would cursor pagination fix it here?
Would your staleness tolerance for click counts change if this were a paid analytics product marketed on real-time insights?
"Design the frontend for a URL-shortening service" is a deceptively small-sounding prompt whose interesting content lives entirely on the frontend side, since the actual shortening logic is a backend concern out of scope for this round. Three decisions make up a strong answer:
Optimistic feedback on submit. A user pastes a long URL, hits "Shorten," and expects the short link back immediately, with copy-to-clipboard as the very next action. The earlier optimistic-updates lesson covers the general pattern; here it applies directly: show the new short link in the UI the instant the request is issued, with a clear pending-then-confirmed state, since generating a short link is cheap and reliably fast enough that the perceived latency is worth eliminating.
The links dashboard as an offset-pagination case. A user's list of previously created links is exactly the case where OFFSET-based pagination is the right choice, not the wrong one — the earlier pagination lesson covers cursor-based pagination as the answer for feeds with frequent inserts (like a social feed); a links dashboard is the opposite shape. It changes far less frequently — a user creates a handful of new links per session, not hundreds of concurrent inserts from other users — so the classic offset problem (rows shifting under you between page requests) barely applies in practice, and offset pagination's real advantage (jumping directly to page 7, showing a total count) is genuinely useful here in a way it isn't for a fast-moving feed.
Click-analytics with real staleness tolerance. Each shortened link accumulates click counts over time. This is squarely an application-cache staleness decision, covered in the earlier client-cache lesson: a click count is the kind of data that's completely fine to show stale for a good while — a link's click count being ten seconds, or even a few minutes, out of date causes no real harm to anyone, so this is a strong, deliberate case for a longer stale-while-revalidate window rather than aggressive real-time refetching.
See it in a real thing: submitting a link and watching its click count grow
A user pastes a URL, clicks submit, and the shortened link appears with a copy button immediately — the request to the backend is in flight, but the UI already shows the expected result optimistically, falling back to an error state only in the rare case the backend actually rejects it. That link then shows up at the top of the user's links dashboard, which loads in pages of twenty, with page numbers and a jump-to-page control — offset pagination, deliberately, since this list is small and slow-changing per user. Each link's click count refreshes lazily, maybe once a minute or on a manual refresh, because a marketer checking their link performance doesn't need sub-second accuracy on a number that's fundamentally an approximation of "roughly how many people have clicked this."
What people usually miss
Watch out
Reaching for cursor-based pagination here out of habit is a common overcorrection. The news-feed lesson makes cursor pagination sound like the modern default, but a slow-changing, per-user list is precisely the case offset pagination was always fine for — naming why this list doesn't have the insert-churn problem a feed has is the actual skill.
Optimistic feedback works here specifically because the action is cheap and reliable. Generating a short link rarely fails and has no meaningful conflict potential — that's what earns the optimism, the same reasoning the optimistic-updates lesson applies to a "like" button.
A click count doesn't need to be accurate to the second, and treating it like it does is over-engineering. Aggressive real-time refetching for a number nobody is watching in real time spends complexity on precision the feature doesn't actually need.
"Boring and correct" is a legitimate answer, not a weaker one. Naming offset pagination and a long staleness window with clear reasoning shows better judgment than defaulting to the more sophisticated-sounding option for every decision in the design.
Why this matters in interviews
A URL shortener is a useful prompt precisely because it looks simple, and a strong answer shows the candidate can pick the right tool for each of its three real decisions — optimistic feedback, offset pagination, and staleness tolerance — rather than defaulting to whichever pattern sounds most advanced.