URL Shortener System Design
An interview-scoped walkthrough of how a Bitly-style URL shortener's core subsystems work — each one built up from the naive first-pass answer to the scaled, production-shaped version, the way you'd actually talk through it in a room.
Minute one — before any subsystem
Scoping "Design a URL Shortener"
A URL shortener sounds simple, which is exactly the trap. An interview goes better with three moves: "I'll start here — take a long URL and hand back a short one, redirect the short one back to the original, and let someone see how their link is doing. That's the whole product in miniature. I'll name what's missing and expand into it once we've nailed this."
The core — say this first
- POST
/api/shortenThe write. Turns a long URL into a short, unique code — every other subsystem exists to serve, protect, or scale this one mapping. URL Shortening & Encoding →
- GET
/{code}The read, and the hard problem. Redirects outnumber creations by orders of magnitude — this is what forces the caching and hot-link conversation, the centerpiece of the interview. Redirection (Read Path) →
- GET
/api/links/{code}The product layer. Without it, a short code is just an anonymous redirect — this is what lets someone manage a link and see how it's performing. Link Management & Click Tracking →
Expand on later
Named up front so the interviewer knows you know they exist — detailed only once the core holds up, or if they ask. Each one is a real subsystem in this guide.
- Key generation
cross-cuttingKey Generation Service → - Caching
cross-cuttingCaching Layer → - Rate limiting
cross-cuttingRate Limiting & Abuse Prevention → - Custom domains
GET /{code} (branded)Custom Domains & Branded Links →
Explicitly out of scope
- Link previews / OG metadata scraping — a content-fetching concern, not a redirect problem.
- QR code generation — a client-side rendering feature bolted onto an existing short code.
- Team workspaces, permissions & billing — an orthogonal auth and monetization system.
- Malicious URL / phishing detection at scale — worth naming as real, but a follow-up, not a first pass.
Non-functional priorities
- Read:write ratio. Redirects outnumber link creations by 100:1 or more — this one fact justifies caching and a fast key-lookup path before anything else does.
- Redirect latency is the product. Every extra millisecond in the read path is felt directly by the end user clicking a link — link creation can tolerate far more slack.
- Availability over strict consistency. A click count that's a few seconds stale from replication lag is fine; a redirect that times out or 500s is not.
How to open with this out loud: name the three core endpoints before drawing a single box, say why each one earns its place, then rattle off the "expand on later" list in one breath — that's what signals you're scoping the problem deliberately, not stalling because you don't know where to start.
Core Data Flow
URL Shortening & Encoding
How does a long URL become a short, unique code that's durably stored?
Link Management & Click Tracking
How does someone see how their link is performing, without click-counting slowing down every redirect?
Redirection (Read Path)
How does GET /{code} resolve fast at massive read volume, without falling over on a viral link?