The URL shortener problem is popular because it is small enough to discuss in one interview and rich enough to reveal how you reason about scale. The mistake many people make is jumping straight to hashing before they define the actual product.
Start with the contract
Clarify the core requirements:
- Create a short URL from a long one
- Redirect quickly from short to long
- Support expiration if needed
- Track basic analytics if the interviewer cares
Nice-to-have questions:
- Custom aliases?
- One-time links?
- Abuse detection?
The happy-path architecture
At a high level you need:
- An API service that accepts long URLs
- An ID generation strategy
- A datastore mapping short code to original URL
- A redirect path optimized for reads
This is already enough for a solid first pass.
ID generation choices
Auto-increment plus base62 encoding
This is easy to explain and compact to store.
Pros:
- short codes are dense
- no collisions
- easy lookup
Cons:
- central coordination for IDs
- sequence predictability unless you add obfuscation
Random string generation
Pros:
- decentralization is easier
- harder to enumerate sequentially
Cons:
- collision checks required
- slightly more complex write path
Read path matters more than write path
Shorteners are usually read-heavy. That means the redirect path deserves most of the optimization effort.
A common pattern is:
- Cache hot mappings in Redis
- Fall back to the primary datastore on cache miss
- Use a CDN or edge layer if geographic latency matters
Database considerations
The mapping itself is simple:
| Field | Purpose |
|---|---|
short_code |
primary lookup key |
long_url |
redirect destination |
created_at |
auditing and analytics joins |
expires_at |
optional TTL logic |
You can store this cleanly in a relational database or a key-value store. The access pattern is simple enough that either can work.
Failure and abuse angles
Good candidates mention:
- invalid or malicious destination URLs
- spam link generation
- redirect loops
- hot key behavior for viral links
Even a quick mention shows you are thinking beyond the toy version.
A simple answer structure
Use this flow in the interview:
- Requirements
- High-level components
- Code generation strategy
- Storage and caching
- Scaling and abuse concerns
That structure keeps the conversation coherent even if the interviewer interrupts halfway through.
Closing thought
The URL shortener is not testing whether you know a fancy architecture. It is testing whether you can keep a small design problem organized while making reasonable tradeoffs under time pressure.