Design: URL Shortener (TinyURL)

10-session plan to master URL shortener design from basics to expert-level trade-off discussions. Session 1: Problem Scoping & Requirements The Interview Opening The interviewer says: "Design a URL shortener like TinyURL." Your first 5 minutes are about scoping — never jump to architecture. Candidate: "Before I start designing, I'd like to clarify requirements. Is this a public service like TinyURL, or an internal tool?" Interviewer: "Public service, similar to TinyURL or bit.ly." Candidate: "Got it. Let me confirm functional requirements: Given a long URL, generate a unique short URL Redirecting short URL to the original long URL Custom aliases — should users be able to pick their own short code? Link expiration — do URLs expire? Analytics — do we need click tracking?" Interviewer: "Custom aliases: nice to have. Expiration: yes, default 1 year. Analytics: yes, basic click counts." Functional Requirements (Final) Core: POST a long URL → receive short URL (e.g., ) Core: GET → HTTP 301/302 redirect to original URL Secondary: Custom alias support ( with preferred alias) Secondary: Expiration timestamps (default: 1 year, configurable up to 5 years) Secondary: Click analytics (count, referrer, geo, timestamp) Non-Functional Requirements Availability: 99.99% uptime — URL redirection is business-critical Latency: Redirect p99 < 10ms (users expect near-instant redirects) Consistency: Short codes must be globally unique — no two URLs can share a code Durability: Once created, a short URL must never be lost Read-heavy: Reads (redirects) vastly outnumber writes (URL creation) Clarifying the Read/Write Ratio Candidate: "What's the expected scale? DAU and requests per day?" Interviewer: "Let's say 100 million new URLs created per day, 10 billion redirects per day." This gives a 100:1 read-to-write ratio — this single fact drives most architectural decisions. You'll optimize the read path aggressively (CDN, cache) and the write path can be simpler. What NOT to Design Be explicit about scope boundaries: No user authentication/login system No URL preview or safety scanning No dashboard UI No A/B testing or campaign tracking Interview Q&A Q: Why 301 vs 302 redirect? A: 301 (permanent) — browser caches the redirect, reducing server load but losing analytics for cached hits. 302 (temporary) — browser always hits your server, giving full analytics. TinyURL uses 301 for performance; bit.ly uses 302 for analytics. Choose based on whether analytics matters more than server load. Q: What happens when a short URL expires? A: Return HTTP 410 Gone (not 404). 410 signals the resource existed but is intentionally gone — better for SEO and client error handling than 404 which implies it never existed. Q: Should we allow the same long URL to get multiple short codes? A: It's simpler to allow duplicates — checking for existing long URLs requires a reverse index and adds write latency. Most systems allow the same long URL to have multiple short codes unless dedup is an explicit requirement. Java Implementation Python Implementation