Skip to content

Functional Requirements

The system

A URL shortener takes a long URL and returns a short one. When someone clicks the short URL, they get redirected to the original. Think bit.ly or tinyurl.com.

The two core flows

Every URL shortener is really two things glued together.

The first flow is shortening — a user pastes a long URL into the system and gets back a short one. Something like bit.ly/x7k2p. That short code is what gets shared on Twitter, printed on business cards, put in SMS messages.

The second flow is redirecting — when someone clicks bit.ly/x7k2p, the system looks up what the original URL was and sends the user there. This happens transparently — the user never sees the lookup, they just land on the destination.

These two flows are independent in terms of load. Shortening is a write. Redirecting is a read. And reads vastly outnumber writes — a single viral link can be clicked millions of times.

What's in scope

  • Shorten a URL — user provides a long URL, system returns a short one
  • Redirect — user clicks a short URL, system redirects them to the original long URL
  • Anonymous access — no login required, anyone can shorten a URL

What you should always ask about

Custom aliases

Can a user request a specific short code? Instead of a random x7k2p, they want bit.ly/my-brand. This is a paid feature on bit.ly. It matters because it changes your ID generation strategy — you can no longer just auto-generate codes, you now have to handle collisions with user-requested names and reserve a namespace.

Expiry

Do short URLs live forever? Or do they expire after 30 days, 1 year, never? This affects two things: your storage estimates (if URLs expire, you can delete old rows and reclaim space) and your cleanup design (you need a background job that purges expired entries).

Analytics

Does the system track how many times each link was clicked? From which country, which device, which time of day? This is a whole separate subsystem — bit.ly charges money for it. If analytics are in scope, you now need an event pipeline alongside your redirect flow, and your storage estimates change significantly.

What if someone shortens a URL pointing to malware or a phishing page? Does the system blindly redirect, or does it check against a blocklist? Google Safe Browsing API exists for exactly this. For SDE-2 you don't need to design the full safety system, but asking the question shows you're thinking about abuse.

Interview framing

The two flows are easy — shorten and redirect. What separates a strong answer is asking the right scoping questions: custom aliases (changes ID generation), expiry (changes storage and cleanup), analytics (adds an event pipeline), and link safety (adds abuse handling). At minimum, ask about custom aliases and expiry — those two directly change how you design the system.