Most answers to "design a URL shortener" start with the final picture: load balancers, a cache cluster, Kafka, ten boxes. Interviewers see that every day. It shows you remember a diagram, not that you can design.
A better answer starts small. Then you let the numbers decide each next step. Here's the short version.
First, the numbers
Say people create 100 million links a month, and each link gets about 100 clicks.
- That's about 40 new links a second. One normal database can handle it.
- It's about 4,000 clicks a second, and maybe 10 times that when one link goes viral. That's a lot of reads, so we'll need a cache.
- Over 10 years we need about 12 billion short codes. Seven characters (letters and digits) give us 3.5 trillion, so 7 is plenty.
So the data is small, and the reads are many. Everything below follows from that.
Step 1: one server, one table
A table that maps each short code to its long URL. One endpoint to create a link, one to redirect. Start here in the interview. It's fine to say it won't last.
Step 2: make codes without waiting
If every new link asks the database for the next number, every server waits on that one database. Instead, each server takes a block of 10,000 numbers at once and hands them out from memory. Two servers never get the same block, so codes never clash.
We also shuffle the numbers with a secret key. Otherwise codes made one after another look alike, and anyone could walk through every link.
Step 3: a cache for clicks
Here's the nice part. A link's target never changes. So a cached copy can be missing, but it can never be wrong. Each click checks a small cache in the server's memory, then Redis, and only then the database.
Step 4: count clicks later
The redirect shouldn't wait for analytics. It drops a small "someone clicked" event into a queue and answers right away. Another job adds up the clicks in the background.
The question that changes the answer
Should the redirect be a 301 or a 302? A 301 tells browsers to remember it forever. You get less traffic, but you stop seeing clicks, and you can't stop a bad link after you delete it. A 302 keeps every click coming back to you. So ask the interviewer about analytics early. It decides this.
When one link goes viral
The traffic itself is fine. The danger is the moment that link drops out of the cache. Thousands of requests miss at once and all hit the database. The fix: keep hot links in each server's memory for a few seconds, and let only one request reload a link while the others wait.
I wrote the full version on my site. It has a diagram you can grow step by step, a calculator for the numbers, "what breaks" scenarios, and code in five languages. It's free, no sign-up: Design a URL shortener
Top comments (0)