The Deceptively Simple Interview Question That Unlocks Everything

There’s a common question in tech interviews that seems almost too easy at first glance. “Design a URL shortener,” they’ll say. You think, how hard could that be? You take a long link, you make it short. Done, right?

But here’s what I discovered when I actually sat down to figure it out: that simple question is a trap door. It opens up into everything that matters in system design. It’s not about making a short link. It’s about what happens when millions of people click it at the same time. That’s where the real thinking starts.

At its heart, the system has one job:

1. Let me give it a massive, ugly web address and get back a cute, short one (like short.ly/abc123).

2. Make sure when anyone clicks that short link, they’re flung to the right website, fast.

The clever bits are in the optional features: letting users pick a custom alias (like short.ly/myblog), or setting a link to expire. What we’re not building today are user accounts, dashboards, or complex tracking. That’s a whole other mountain to climb.

The Secret: It’s All About The Click

Here was my lightbulb moment. This system isn’t used equally. For every 1 person creating a short link, about 1,000 people are clicking on one. It’s a read-heavy monster. Your entire design must bow down to one god: making the redirect blindingly fast.

The goal? That click should land and redirect in under 100 milliseconds, 99.99% of the time. That means for a billion links and 100 million daily users, your system needs to be built like a highway, not a neighborhood road.

Building The Machine, One Piece at a Time

We need two simple doors (APIs) into our system:

• A POST /urls door where you hand over the long URL and get back the short one.

• A GET /{short_code} door (like short.ly/abc123) that instantly shoots you to your destination.

Walkthrough: From Long to Short and Back

1. Creating the Link:
You paste https://a-ridiculously-long-website-name.com/article and hit submit. The system checks it, then invents a unique, short code for it (like abc123). This is trickier than it sounds. Making millions of unique short codes is a puzzle we’ll dive into. It then tucks this pairing (abc123 -> long URL) safely into a database and hands you your new short link.

2. The Magic Click:
This is where the engine revs. Someone clicks short.ly/abc123. The system can’t afford to dig through a filing cabinet (the database) every single time that would be too slow. Instead, it looks in its lightning-fast, short-term memory (a cache). It finds the code abc123 in milliseconds, remembers the long URL it points to, and immediately sends back a gentle shove (an HTTP 302 redirect) to your browser saying, “Go there, now!”

Why a 302 redirect and not a 301? Because 302s are temporary. They let us change our minds later useful if a link expires or we need to track a click. A 301 tells your browser to remember the destination forever, which breaks our control.

The Deep-Dive Puzzles

This is where my initial design fell apart.

1. How do you make millions of unique short codes?
You can’t just guess randomly; you might get duplicates. One solid way is to use a global counter. Think of it as a ticket dispenser in Karachi. Every time a new link is made, it takes the next number (1, 2, 3…), and then encodes that number into a short string of letters and numbers. The challenge? That “ticket number” needs to be unique across the entire planet, even if thousands of machines are creating links at once.

2. How do you handle the stampede of clicks?
With 1000x more reads than writes, you cache aggressively. The short code and its destination should live in a super-fast memory store (like Redis) right after it’s created. You also separate the traffic. The service that handles clicks (the Read Service) becomes a streamlined, caching powerhouse, completely separate from the service that creates links (the Write Service). This way, the click traffic can’t overwhelm the creation process.

3. How do you scale the “unique ticket” machine?
That global counter can’t be a bottleneck. The solution is batching. Instead of asking the central store for a single new number every time, each Write Service asks for a chunk of numbers (say, 10,000 at a time). It then hands them out locally one by one. This reduces the chatty, slow traffic to the central store by a factor of 10,000.

The Simple Truth I Learned

Designing a system like this isn’t about proving you know the fanciest tools. It’s about matching simple, robust choices to a very lopsided problem. You choose a database that can handle the writes (which are low), you build everything around caching for the reads (which are massive), and you carefully manage that one shared resource. The unique code generator so it doesn’t slow down the party.

On to Day 04.

Take Care.