URL Shortener
The 'hello world' of system design — every concept in miniature.
You're asked: "Design a service like bit.ly." Long URLs go in, short codes come out, and visiting a short link redirects to the original.
This case looks tiny but contains the full interview arc: requirements → estimation → a simple design → the moment it breaks → the fixes. Interviewers love it because every decision you make has a why they can probe.
How to play any system design round: never jump to architecture. Spend the first minutes nailing down what you're building and how big it is — the numbers you produce will justify every box you draw later.
01Requirements
First, split requirements into functional (what it does) and non-functional (how well it must do it).
Functional
- Shorten: given a long URL, return a short code like
np.io/x7Kp2a - Redirect: visiting a short link sends you to the original URL
- (Clarify with the interviewer) custom aliases? expiry? click analytics? — we'll say yes to analytics later, no to the rest
Non-functional
- Read-heavy: redirects vastly outnumber shortens — assume 100:1
- Low latency on redirect (it's in the critical path of a user clicking a link)
- High availability: a dead shortener breaks every link ever created
- Short codes must be hard to guess (don't expose sequential IDs)
The single most important sentence you can say at this stage: "This is a read-heavy system, so I'll optimize the redirect path." Everything that follows hangs off that observation.
Functional = features (shorten, redirect). Non-functional = qualities (latency, availability, scale). Juniors list features; seniors lead with qualities, because qualities decide the architecture.
Checkpoint
Why does 'read-heavy, 100:1' matter so much for this design?