The brief
Build a service that turns long links into short, shareable URLs. Your design should meet these requirements:
- A user submits a long URL and receives a short link.
- Opening a short link redirects to its destination with low latency.
- Link creation and redirect traffic can grow independently.
Scale to design for
Assume ~100M new links/month and a read:write ratio around 100:1 (tens of thousands of redirects/s at peak). Redirect latency is the critical path; creation can be slower. Links may be permanent or expire; custom aliases are optional.
State these assumptions out loud in the interview, then let them drive your choices: they decide what needs caching, sharding or asynchronous processing.
Before you start
You'll get more out of this round if you're comfortable with:
- HTTP redirects (301 vs 302)
- Hashing and base62 encoding
- Key-value stores
- Read-through caching
Questions an interviewer may ask
Expect follow-ups like these once your high-level design is on the board. Have an answer, and a reason, for each:
- How do two API instances avoid issuing the same code?
- What happens on a cache miss storm for a viral link?
- How would you shard the store?
- How do you expire links?
- How do you prevent enumeration or spam?
Common mistakes to avoid
- No strategy for unique codes across multiple instances
- Synchronous analytics writes on the redirect path
- No cache for a read-heavy workload
- Ignoring abuse (malicious URLs, enumeration of sequential codes)
Concepts this round covers
- Read-heavy traffic
- Unique short codes
- Link expiration
- Storage
What a complete answer covers
A request/redirect architecture, a short-code strategy, a storage model, and a plan for cache behavior and growth.
There is no single correct design. A strong answer meets the requirements at the stated scale and explains the trade-offs behind each choice. New to the format? Read how to prepare for a system design interview.