Design URL Shortener
Practice system design: Build a URL shortener like bit.ly with analytics, custom URLs, and scaling.
What is a URL shortener?
A URL shortener stores a mapping from a compact code to a longer destination URL. Creating a link writes that mapping; opening the short link reads it and returns an HTTP redirect.
That simple contract produces an interesting design problem because redirects vastly outnumber creations. The read path must be globally fast and highly available, while the write path must prevent duplicate codes, support custom aliases, and stop harmful destinations from abusing the service.
This walkthrough uses a deliberately large target: 100 million creations and 10 billion redirects per day. The goal is not to memorize a vendor stack. It is to turn requirements into estimates, make the critical path visible, and defend each trade-off.
Begin with the contract, not the components
An interviewer can change one requirement and invalidate half the architecture. Ask which actions matter, which guarantees users can observe, and which capabilities are explicitly outside the first version.
Functional
Core user actions
- Create a short link from a valid
httporhttpsURL. - Redirect a short code to its current destination.
- Optionally choose a custom alias and expiration time.
- Disable a link and view delayed aggregate analytics.
Non-functional
Service promises
- Redirect P95 below 100 ms for the target regions.
- Redirect availability of 99.99%; creation availability of 99.9%.
- No two active mappings may own the same short code.
- Analytics may be delayed and may occasionally lose events.
Guardrails
Safety and tenancy
- Reject malformed and blocked destinations.
- Rate-limit creation by account, API key, IP, and risk score.
- Prevent easy enumeration of sequential internal IDs.
- Isolate branded domains and quotas by tenant.
Out of scope
First-version boundary
- No destination content hosting or proxying.
- No strongly consistent real-time analytics dashboard.
- No arbitrary destination rewriting at the edge.
- No promise that deleted codes can be immediately reused.
Four decisions that shape the design
- Redirect behavior: start with
302 Foundso links can be disabled or changed; control caching explicitly with response headers. - Anonymous access: allow a small creation quota with stricter abuse checks; require an account for bulk APIs, custom domains, and long retention.
- Expiration policy: expired links return
410 Gone; do not immediately recycle codes. - Consistency boundary: creation and custom-alias reservation are strongly consistent; analytics and most read replicas may be eventually consistent.
The hardest invariant is code ownership: at most one active mapping for a short code. The highest-volume path is redirect lookup. Keep those two concerns separate as the design develops.