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.