System Design: Building a URL Shortener Like Bit.ly

Designing a URL shortener is one of the most popular system design interview questions. It tests your ability to think about scale, database design, caching, and distributed systems. In this guide, we will walk through a complete design for a service similar to Bit.ly that handles billions of URLs.

First, let us clarify the functional requirements. The service should allow users to submit a long URL and receive a shortened version. When someone visits the short URL, they should be redirected to the original long URL. Optionally, users may want custom short links, expiration dates, and analytics on click counts. The non-functional requirements include high availability (the redirect service should never go down), low latency (redirects should happen in milliseconds), and the ability to handle massive scale (assume 100 million new URLs per month and a 100:1 read-to-write ratio).

For the API design, we need two primary endpoints. The first is a POST endpoint for creating short URLs, accepting the long URL and an optional custom alias in the request body, and returning the short URL. The second is a GET endpoint that takes the short code as a path parameter and returns a 301 or 302 redirect to the original URL. A 301 redirect tells the browser to cache the redirect permanently, reducing load on our servers. A 302 redirect means the redirect is temporary, which is better if we want to track every click for analytics.