URL shortener system design
Build the service that creates short links and sends each click to the right page.
The problem
A URL shortener turns a long web address into a short one:
https://shop.example/summer-sale/shoes?ref=mail → https://sho.example/x7Kp2
When someone opens the short link, your service finds the long address and sends the browser there (a redirect).
People use short links in posts, texts, QR codes and posters.
Questions to ask the interviewer
What is in scope?
- Create a short link for a long one.
- Send each click on a short link to its long one.
- Not in this problem: accounts, custom names, expiry dates.
How fast must a redirect be?
Under 300 ms on average, for 99% of the clicks.
How many new links, and how many clicks?
- 100M new links a month ÷ 2.6M seconds in a month ≈ 40 new links a second.
- About 100 clicks per link: 40 × 100 ≈ 4,000 redirects a second.
- Many more clicks than new links: reads win.
How much data do we store?
1B links × 500 B each ≈ 500 GB: small enough for one machine.
Must every short id be unique?
Yes. Two long links must never get the same short id.
Want to try it yourself first? Play, then come back for the approach.
PlayThe design in short
A URL shortener looks like a toy, and that is why interviewers like it. The whole product is two calls: make a short id for a long address, and turn a short id back into that address. Everything interesting comes from the gap between them.
Reads win by far. Each link is made once and opened many times. So the redirect path decides your design, and the create path can be plain. Ask yourself which of the two must stay fast when traffic grows, and spend your effort there.
The id is the one hard rule. Two long links must never share a short id. Say how you would make sure of it, and where in the design that promise is kept.
Parts worth a sketch before you commit:
- the app tier behind the clicks, and how many machines the click rate you were given calls for
- where the links live: the data is small, so one database can hold it all
- what keeps a redirect fast when the same rows are asked for again and again
- how a new link gets saved, and what its creator waits for
Reason about scale in steps. Start from the numbers in the brief: new links a month, clicks per link, bytes per row. Turn them into requests a second and gigabytes. Then check each part against them, one at a time, and keep some room spare. A part that runs at its limit on a normal day has nothing left for a bad one.
Know what is out of scope. The brief leaves out accounts, custom names and expiry dates. Each one would add a table, a rule or a check, so say that you heard it and move on. A short, clear design beats a long one that tries to cover everything.
On the GonnaCrash board you draw this yourself and send the clicks through it. The first design that holds is rarely the cheapest one.
Last updated 22 October 2026