News · New this week
URL shortener design: how Bitly opens a page from 7 characters
The short code is a counter number written in 62 symbols, and a click goes through a cache, a key-value store and a redirect.
Bitly doesn't scramble your link into a code. The code is a counter number, written in a short alphabet. Everything else in the design exists to make that number cheap to create and fast to look up.
The code is a counter
When you create a link, the request goes from the browser to an API server. That server uses a number from its own block of numbers and turns it into the code.
To keep the code short, we write the number using sixty-two symbols. That's ten digits, plus small letters and capital letters. A big number written in 62 symbols takes far fewer characters than the same number written in digits.
Why seven spots is enough
A code has seven spots, and each spot holds one of 62 options. That gives about 3.5 trillion codes. For a service handling billions of links, that's plenty of room.
One counter, many servers
A single shared counter gets awkward once you run many API servers. They'd all wait on it, and it becomes a queue. The fix is to split the counter up. Each server owns its own block of a million numbers.
So creating a link doesn't mean standing in line behind every other server. Each one works from the numbers it owns.
Saving and finding the link
The new link has to live somewhere. That's a key-value store. The code is the key, and the long URL is the value. A lookup takes one code and returns one URL.
Putting a cache in front of the store makes clicks quick. The cache, Redis in the reel's diagram, holds a nearby copy of popular links. Those are the hot links.
What happens on a click
Someone clicks a short link. The API server asks the cache first. If the code is there, it has the long URL already. If it's missing, the key-value store answers.
Then the server sends a 301 redirect with the long URL, and the browser goes to the real page.
The whole path is four steps. Counter, cache, store, redirect.
Try sketching this on paper before your next system design interview, with the counter blocks on the API servers and the cache sitting ahead of the store. Then decide whether you'd cache every link or only the hot ones, and be ready to say why.
