Among common system design interview prompts, the URL shortener stands out as one of the most beginner-friendly. It is not valuable because it is deeply complex, but because it offers a clean way to practice reasoning through a real system one layer at a time.
Product Requirement
Functional Requirements
- A user can submit a long URL and get back a shorter version
- Optionally, they may choose their own alias
- Optionally, they may set an expiration time
- When someone visits the short URL, they should be redirected to the original link
Non-Functional Requirements
- High Availability
- Low Latency Redirection
- Scalability — millions of URL mappings and redirects per day
- Reliability — Links must not break
There’s a clear asymmetry in how this system is used: reads dominate writes by a wide margin. A link might be created once but resolved repeatedly, often at a much higher frequency. This access pattern becomes a key driver behind decisions around caching strategy and data storage.
Design Setup
Data Model
- User (who created the link)
- Original URL (the full link)
- Short URL (the generated identifier)
API Design
Once the core entities are clear, the next step is to establish how the outside world communicates with the system.
This is where the API comes in. It defines the contract between clients and the backend, and getting that contract right early makes the rest of the design much easier to reason about.
To create a short link:
POST /urls { "long_url": "https://www.chillinterview.com/long-url", } -> { "short_url": "http://short/chill123" }
To handle redirection:
GET /{short_code}
The server responds with an HTTP redirect (typically 302), sending the user to the original URL.