A deep dive into the architecture behind TinyURL at Scale — from URL encoding to high-speed redirects.
When you submit a long URL, it goes through a carefully designed pipeline to produce a short, unique identifier:
The input URL is validated for proper format (must include a valid protocol like http:// or https://) and checked against disallowed patterns.
A SHA-256 hash of the normalized URL is computed and looked up in the database. If this exact URL has been shortened before, we return the existing short link instead of creating a duplicate — saving storage and keeping IDs compact.
If the URL is new, a sequential integer ID is assigned by the database via an auto-incrementing primary key. This sequential ID is the foundation for our short code.
The integer ID is encoded into a Base62 string using the character set 0-9, a-z, A-Z. For example, ID 1000 becomes “g8” — just 2 characters. Base62 can represent over 56 billion unique URLs in just 6 characters.
The final short URL (e.g. snip.nilambarsonu.me/g8) is returned to the user and stored alongside the original URL, its hash, and metadata.
Before creating a new short URL, we compute a SHA-256 hash of the long URL and query a unique index on the hash column. This gives us O(1) deduplication lookups, ensures idempotent URL creation, and prevents the ID space from growing unnecessarily.
Hash-based short codes (e.g. first N characters of SHA-256) can produce collisions and aren't as compact as sequential Base62 IDs. By decoupling the dedup hash from the short code, we get the best of both worlds: collision-free short codes and efficient duplicate detection.
To prevent abuse, the API enforces rate limits on the shortening endpoint. Each client IP is tracked and allowed a fixed number of requests per time window. Exceeding the limit returns a 429 Too Many Requests response with a Retry-After header.
When a user visits a short URL, the server decodes the Base62 slug back to the integer ID, looks up the original URL in the database, and issues an HTTP 301 (Moved Permanently) redirect. The 301 status code allows browsers and CDNs to cache the redirect, reducing subsequent latency to near-zero.
A 301 redirect is permanent and cacheable. Browsers remember it, so repeat visitors skip our server entirely. For a URL shortener where mappings never change, 301 is the correct choice for performance.