Interview Walkthrough: URL Shortener

The URL shortener is the most frequently asked system design interview question because it is deceptively simple on the surface but reveals significant depth when explored. The core problem is straightforward: given a long URL, produce a short alias that redirects users to the original. But once you start quantifying scale, choosing an encoding strategy, and designing for availability, the problem expands into a rich discussion of distributed systems trade-offs.

Start by clarifying functional requirements: shorten a URL, redirect via short code, support custom aliases, set optional expiration, and provide basic click analytics. Then quantify scale. If the service creates 100 million URLs per day and the read-to-write ratio is 10:1, that means 1 billion redirects per day, or roughly 12,000 QPS for reads and 1,200 QPS for writes. Over five years, the system stores approximately 180 billion URLs. Each record is small (roughly 500 bytes for short_code, long_url, created_at, user_id, and expiry), yielding about 90 TB of total storage. These numbers immediately tell you that reads dominate, caching is essential, and the database must be horizontally partitioned.

The API surface is minimal. A POST to /api/v1/urls with a JSON body containing the long URL (and optional custom alias and expiry) returns the short URL. A GET to /:shortCode returns an HTTP 301 (permanent redirect) or 302 (temporary redirect, better for analytics) pointing to the original URL. The 301 vs 302 decision matters: 301 allows browsers to cache the redirect, reducing server load but losing visibility into click counts. Most production shorteners use 302 or 307 to ensure every click hits the server for analytics.

The encoding strategy is the heart of the design. Three common approaches exist. First, base62 encoding of an auto-incremented counter: a centralized or distributed counter generates a unique integer, which is converted to a 7-character base62 string (62^7 = 3.5 trillion possible codes). This guarantees uniqueness but requires a coordinated counter, which is a potential bottleneck. Second, MD5 or SHA-256 hashing of the long URL, truncated to 7 characters: this is stateless and can run on any node, but truncation creates collision risk that must be handled by checking the database and appending characters if needed. Third, a pre-generated key service that creates random keys in batch and stores them in a pool; workers claim keys from the pool, eliminating both the counter bottleneck and the collision check. Each approach involves a different trade-off between coordination, collision risk, and operational complexity.

A URL shortener works like a coat check at a concert venue. You hand over your bulky coat (the long URL) and receive a small numbered ticket (the short code). When you return with the ticket, the attendant retrieves your coat instantly by looking up the number. The attendant does not need to examine every coat -- the ticket maps directly to a storage slot. If the venue is very popular, they might have multiple coat check stations (database shards) each handling a range of ticket numbers, and a front desk (cache) that remembers the most recently checked coats for faster retrieval.