World 1 /Easy /System design
Design a URL shortener
Learn the design, watch it break five ways, then build one that survives launch day.
Start world 1 8 steps / 4 ready now
The path
Learn the design first. Then each trap breaks one part of it. Last, you build the whole thing yourself.
- 1 LearnWhat we are buildingThe features and the numbers every later decision depends on.Read
- 2 LearnHash or counterHow the short code gets made, and what each choice costs.Read
- 3 TrapThe ID collisionTwo requests read the counter at the same instant and get the same code. Play
- 4 TrapThe stale redirectThe cache keeps sending visitors to a destination the owner already changed.In progress
- 5 TrapAnalytics on the hot pathRecording a click makes the redirect itself slow.In progress
- 6 TrapThe vanity alias raceTwo users claim /launch at once, and both are told it is theirs. Play
- 7 TrapCleanup at scaleOne DELETE of expired links locks the table everyone redirects from.In progress
- 8 BuildBuild itPick the code pattern for every step, then let every request ordering run and see which traps your design falls into.In progress
Step 1
What we are building
Every decision later in the track comes back to these. Say them out loud first in an interview.
It must
- Turn a long URL into a short code, and redirect anyone who opens it
- Let people pick a custom alias like /launch
- Let the owner change where a link points
- Expire links after a set time
- Count clicks for the owner
At this scale
- New links
- 100M / month
- about 40 writes a second
- Redirects
- ~4,000 / s
- 100 reads for every write, 10× at peak
- Stored links
- ~6B rows
- kept for five years
- Redirect budget
- < 50 ms
- it sits in front of every click
The number that shapes everything: 100 reads for every write. Optimise the redirect first.
Next: Hash or counterRun every bug yourself
Each trap is runnable code against a real Postgres in the repo.