Design a URL Shortener (TinyURL / Bitly Architecture)

URL shorteners convert long URLs (e.g. 150 characters) into concise aliases (e.g. https://sho.rt/aX9z3), serving massive 100:1 read-to-write redirect traffic.

1. System Requirements

Functional Requirements

1. Shorten URL: Given a long URL, return a unique 7-character short alias.
2. Redirect: Accessing the short link redirects the user to the original destination URL.
3. Analytics: Track total clicks and click timestamp metrics.
4. Custom Aliases: Optional user-specified vanity URLs (e.g. /black-friday).

Non-Functional Requirements

1. Low Redirect Latency: Redirections should complete in $< 20\text{ms}$.
2. High Availability: 99.999% uptime for redirect resolution.

2. Base62 Encoding & Unique ID Generation

A 7-character alphanumeric string using Base62 characters ([a-z, A-Z, 0-9]) provides: $$62^7 \approx 3.52 \times 10^{12} \text{ (3.5 Trillion unique short URLs)}$$

Distributed ID Generator (Snowflake Pattern)

Rather than hashing the URL (which causes collisions and requires database lookups), generate a 64-bit integer using a distributed ID generator (Twitter Snowflake), then convert that integer directly to Base62:

ID: 10,000,000,000 -> Base62: "aZ4b1q"

3. HTTP 301 vs. HTTP 302 Redirection

• 301 Moved Permanently: Browsers cache the redirect locally. Subsequent clicks bypass the URL shortener server completely.
• *Pros*: Lowest server load.
• *Cons*: Analytics (click counts) cannot be recorded for cached clicks!
• 302 Found (Temporary Redirect): The browser always queries the URL shortener on every click.
• *Pros*: 100% accurate click analytics and tracking.
• *Cons*: Higher server traffic.

Key Architecture Trade-Offs & Decision Matrix