A URL shortener looks like the easiest system design question you will ever get. Store a mapping, hand back a short string, redirect. You could write it in an afternoon.

That is exactly why it gets asked. The naive version really is trivial — so the interview is not about whether you can build it. It is about whether you notice the four decisions hiding inside the triviality:

1. How short can the code be? Not a guess — an arithmetic answer from the traffic estimate.
2. How do you generate the code? Hash the URL, or encode a counter? They fail in completely different ways.
3. 301 or 302? One of these silently destroys your analytics and makes links impossible to change. Most candidates pick it.
4. What stops your service becoming a phishing tool? Every real shortener spends more engineering effort here than on the shortening.

We will build it properly, in the order an interviewer expects, and then cover the production concerns the textbook treatment leaves out.

Every row in your database needs a name. For years that name came from one line of SQL:

CREATE TABLE orders (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  ...
);

The database hands out 1, 2, 3, 4. They are unique, they are sortable, they are small. It is a solved problem — right up until the moment you have two databases.

Then it stops working, quietly and catastrophically. Both databases happily hand out ID 1. Two different orders, same identifier. Your foreign keys now point at the wrong rows, and no error was raised anywhere.

Amazon DynamoDB stores hundreds of trillions of items and handles tens of millions of requests per second at peak. Netflix uses it to keep track of what you were watching. Airbnb uses it for availability calendars. Discord uses it for message storage.

What do all of these have in common? They all need to store and retrieve data by a simple key — blazingly fast, at global scale, with near-zero downtime. That’s what a key-value store does.

It’s 11:59 PM on Black Friday. Your e-commerce platform has been running smoothly all day. Then at midnight, 500,000 shoppers simultaneously hammer your /checkout API. Your servers start queuing requests. Then they start dropping requests. Then they crash. Every second of downtime costs thousands of dollars in lost sales.

Meanwhile, a competitor’s site — running the exact same infrastructure — handles the load just fine. The difference? They had a rate limiter.