Design a URL Shortener (bit.ly / TinyURL)
The URL shortener is the most-asked "warm-up" system design question, and interviewers use it precisely because it looks trivial. A short-link service has one write path and one read path, yet it forces you to reason about ID generation under concurrency, read-heavy caching, redirect semantics, sharding, expiry and abuse — the same building blocks that appear in every larger design. A candidate who hand-waves the key-generation step or picks a 301 redirect without mentioning analytics signals that they have not thought about the trade-offs.
This subject is written as a model answer following the four-step framework from the System Design Interview Framework subject: clarify requirements → estimate → high-level design → deep dives, finishing with the follow-up questions interviewers actually ask. Numbers are worked out explicitly because interviewers want to see arithmetic, not adjectives.
Sibling topics are referenced but not re-taught: how the cache layer behaves is covered in the Caching Strategies subject, token buckets in Rate Limiting, hash-ring placement in Consistent Hashing, and replication mechanics in Database Replication and Sharding.
Step 1 — Requirements
Spend the first three to five minutes here. Ask, do not assume.
Functional requirements
| # | Requirement | Clarifying question to ask |
|---|---|---|
| F1 | Shorten: given a long URL, return a short URL | Fixed length? Custom domain? |
| F2 | Redirect: GET /{key} sends the browser to the original URL |
Must every hit be recorded? |
| F3 | Custom alias: user may request short.ly/my-launch |
Reserved words? Case-sensitive? |
| F4 | Expiry: optional TTL per link, default e.g. 5 years | What happens to expired keys — reuse or tombstone? |
| F5 | Analytics: click count, referrer, country, per link | Real-time or hourly is fine? |
| F6 | Accounts / API keys (light): rate limits per user | Anonymous shortening allowed? |
Non-functional requirements
- Read-heavy: ratio of redirects to creates around 100:1.
- Low-latency redirects: p99 well under 100 ms — a redirect is on the critical path of a page load.
- High availability: a shortener that is down breaks every link ever shared. Prefer availability over strict consistency (an occasional stale click count is fine; a failed redirect is not).
- Unpredictable keys: users should not be able to enumerate other people's links.
- Durability: links must not be lost; a link created today should still resolve in five years.
State the priority out loud: "Redirect latency and availability dominate; write throughput is modest; analytics can be eventually consistent." That sentence drives every later decision.