!This gives away every stage. For a clean attempt, practise it first, then come back.

Before we start

Think about the last time you shared a long link in a WhatsApp group. It probably got shortened along the way, to something like bit.ly/3xYz. Someone tapped it, and a fraction of a second later they were on the real page. That tiny hop is what you’re designing.

The basic version is easy: store the short code, look it up, send the user on. Most people finish that in ten minutes. The interviewer then has half an hour left, and that’s where the real interview happens. They’ll ask what breaks when a link goes viral, how you make codes, how you count clicks.

So the goal isn’t just to draw boxes. It’s to show why each box is there. We’ll go in the order that works best in a real interview:

1. Agree on what the system must do, and how well.
2. Do a little maths to find out what’s actually hard.
3. Name the main pieces of data and the API.
4. Start with the simplest design, and add to it each time growth breaks something.
5. Go deep on the parts the interviewer pushes on.

The chat bubbles are what you’d say out loud. The text around them explains the thinking.

Minutes 0–5Requirements

Every one of those questions changes the design. That’s the test: if an answer wouldn’t change anything you draw, you didn’t need to ask it.

Functional requirements

These are the things the system does, most important first:

1. A user can turn a long URL into a short link, optionally choosing their own code and an expiry date.
2. Anyone who opens a short link is sent to the original page.
3. The person who made the link can see how many clicks it got each day, by country and by source.

Things we’re not building today, said out loud so the interviewer can disagree: sign-up and login, editing where a link points, QR codes.

Non-functional requirements

These are about how well it works. Each one will shape the design later, so give it a number where you can.

1. Fast: a redirect should take under about 50 ms on our side. Nobody wants to wait before the real page even starts loading.
2. Always up: opening a link should work 99.99% of the time. A short link might be printed on a poster or saved in a PDF. If we’re down, all of those break. Creating links can be a little less reliable.
3. Permanent: a code always points to the same URL, and a code is never handed out twice.
4. Big, and mostly reads: 100 million new links a month, each opened about 100 times.
5. Hard to guess: nobody should be able to try codes one by one and find links other people made.
6. Click counts can be a few minutes late.

Minutes 5–10Back-of-the-envelope estimates

Notice the last line of the conversation. Doing maths is fine, but the useful part is saying what the numbers mean for your design. “Creating links is easy” tells the interviewer where you won’t spend time.

Why does the size of the code space matter? Later we’ll pick codes at random. The chance a random code is already taken equals how full the space is. And it fills up a little more every year:

With six characters, after ten years one new code in five would clash with an existing one. With seven, it’s one in about 300. That’s why seven is the usual choice.

Minutes 10–15Core entities and the API

Core entities

Three kinds of data carry the whole system:

• Link: the short code, the long URL, who made it, when, and when it expires.
• Click: which code, when, from which country and which site. A new click record is added each time, never changed.
• User: exists, but login is out of scope today, so we only store who made each link.

Keeping clicks as separate records (instead of a “clicks” number on the link) matters later, when a link goes viral.

The API

The interesting choice is the redirect. HTTP has two common ways to send a browser somewhere else: 301 means “this has moved for good”, and 302 means “go here for now”.

That second answer is the one interviewers remember. bit.ly itself sends a 301 together with “remember this for 90 seconds”, so it gets the best of both.

Two more small things worth mentioning:

• Safe retries: if the user’s app times out and sends the create request again, we shouldn’t make two links. The client sends a unique key with each request (an idempotency key, see lesson 1.5), and we return the same link for the same key.
• Only allow web links: accept http and https addresses only. Some other kinds of links can run code in the browser.

Minutes 15–25The design, built up

Here’s the approach: start with the simplest thing that meets the functional requirements. Then imagine the app growing. Each time something breaks, add the piece that fixes it, and say why.

Stage 1One server, one database

This already does everything on our functional list, and it’s worth saying so. A single Postgres database can handle thousands of lookups a second, so speed isn’t the first problem. Staying up is. If that one server restarts, every short link in the world stops working. That breaks our 99.99% goal on day one.

Stage 2Reads grow: stateless servers and a cache

Usually caches are tricky, because when the real data changes, the cached copy goes stale. But our links never change. A cached link is never wrong. The only catch is expiry: we store the expiry date in the cache too, and never keep a cached link past it.

(Load balancers are covered in lesson 2.2, caching in lesson 2.4.)

Stage 3Global and viral: an edge, split paths, a store that partitions

Try each kind of request and see where it gets answered. Very little reaches the database:

You might notice two caches now: Redis, and a small one inside each redirect server. Why both? Every trip to Redis still crosses the network, and every request for the same link goes to the same Redis machine. A tiny in-memory copy on each server (a few thousand popular links, kept for 30 seconds) takes the load off for the hottest links. In most systems, 40 servers each keeping their own copy is a recipe for 40 different answers. Here the answer can’t change, so it’s safe.

One thing to know about databases that spread data across machines: each piece of data lives on one machine, and that machine has a limit. In DynamoDB, a single partition handles about 3,000 reads a second. A viral link sending 12,000 reads straight to the database would get throttled, no matter how big the whole table is. That’s why the caches in front aren’t optional.

Stage 4Analytics without slowing redirects

(Queues like Kafka are covered in lesson 4.1.)

Checking the design against the requirements

Before going deeper, walk back through your list. It takes thirty seconds and catches gaps before the interviewer does.

Deep diveGenerating unique codes

Bad solutionHash the URL and cut it short

Run the long URL through a hash function (like MD5) and keep the first seven characters. It sounds neat, because the same URL always gets the same code. But nobody asked for that. And because you cut the hash short, two different URLs can still end up with the same seven characters. So you need a “check and try again” step anyway, and the hash didn’t really buy you anything.

Good solutionA counter

Count up: link 1, link 2, link 3, and write each number in base62. Codes never clash, and they stay short. But think about what that reveals. If your link is x7Kp2Qa, anyone can try x7Kp2Qb, x7Kp2Qc and so on, and find other people’s links. People shorten links to private documents and unlisted videos, assuming nobody can find them. Researchers have done exactly this kind of scan on real shorteners and found private files. A counter also tells competitors how many links you make: take two codes a week apart and subtract.

Great solutionRandom codes, and let the database say no

Pick seven random characters, then save the link with an instruction that only works if the code isn’t taken yet. In Postgres that’s INSERT … ON CONFLICT DO NOTHING. If the code was taken, pick another one and try again. With 0.34% of codes used, that happens about once in 300 tries. Nobody needs to coordinate anything: the database’s uniqueness check is the referee. Custom codes go through the same check, so they can never clash with random ones.

If your company really needs counters (some systems do), you can still hide the order. Run each number through a reversible scramble with a secret key, so 1, 2, 3 come out looking random but never repeat. The general idea is called format-preserving encryption, and it’s a nice thing to mention if the interviewer pushes.

Deep diveThe viral link

Lesson 2.4 shows a stampede and its fixes:

Deep diveCounting 5,000 clicks a second

Bad solutionAdd one to a counter on every click

UPDATE links SET clicks = clicks + 1 on every redirect. For a viral link, every click has to wait its turn to update the same row, and the user is waiting too. Lesson 4.5 shows how quickly that queue grows.

Good solutionSend click events to a queue

Drop a message per click into Kafka and count later. This is the right idea, with a hidden trap. Kafka splits a topic into partitions, and keeps messages in order within a partition. The obvious choice is to group messages by short code. But then one viral link sends all its clicks to one partition, which only one worker reads:

Great solutionCount a little first, then send

Each redirect server keeps a small tally in memory (“x7Kp2Qa: 212 clicks this second”) and sends one summary per second, to a random partition. The counting job adds the summaries up. Forty servers send at most forty messages a second, however viral a link gets. We lose the order of individual clicks, but counting never needed it.

Three more things worth knowing about click data:

• Link previews aren’t people. When you paste a link into WhatsApp, Slack or iMessage, their servers open it to build the preview card. Filter those out, or your counts are inflated.
• Messages can arrive twice. If a counting job crashes halfway, it may process the same batch again. Design it so counting a batch twice gives the same result, or accept a small, known error.
• Unique visitors don’t need a list of everyone. A HyperLogLog estimates “how many different people” in about 12 KB per link, with under 1% error. Lesson 4.5 explains how.

Deep diveExpiry, deletion, and never reusing codes

Real-world reminder: in 2024 Google announced that all goo.gl links would stop working in 2025. People pushed back hard, because those links were inside documents, videos and posts that nobody could edit any more. Google later kept the links that were still being used. A short link is a promise that lasts longer than you’d think.

Deep diveStopping scams

That last point usually comes from people who’ve actually run one of these. It’s one reason X uses t.co instead of a path on x.com.

Deep diveUsers all over the world

Here’s the story. Someone in Mumbai creates a link and shares it in a group chat. A friend in Frankfurt taps it 200 milliseconds later, before the link has been copied to Europe. Try both options:

Remembering “this code doesn’t exist” seems smart, because bots try random codes all day. But combined with the copying delay, a 200 ms gap turns into a full minute where the link is broken for everyone in Europe. Two fixes: never remember “not found” for more than a second or two, and if a code is missing locally, ask its home region before saying 404. You can even hide the home region inside the code itself, using a tiny bit of it, so the redirect server knows where to ask.

(Replication lag, the delay before copies catch up, is covered in lesson 2.5.)

The complete architecture

Here’s everything together: the full design from the last stage, with every part we added along the way. If you only remember one picture from this question, make it this one.

How one request travels through it:

1. A browser opens chrp.in/x7Kp2Qa. If the edge has a cached 302 for it (popular links, a few minutes’ max-age), it answers without touching us.
2. On a miss, the load balancer sends it to any redirect server. They are stateless, so you add more by number, not by design.
3. The redirect server asks Redis for the code. For the hot set, this is the whole lookup: sub-millisecond.
4. On a cache miss it reads the links store by primary key, checks expires_at, fills the cache, and replies 302.
5. It fires a click event at the log without waiting and moves on. If the log is slow, redirects aren’t.
6. A rollup job reads the log in batches and upserts per-minute and per-day counts. A link clicked a million times is a million events, but only one write per minute to the analytics table.
7. Creates take the other branch: generate a random code, insert it only if absent, retry on the rare conflict, and return it.

How this answer gets scored

Interviewers don’t tick boxes, but their notes on this question tend to land on the same few moments. Here’s what each one sounds like from the other side of the table.

What the left column has in common: every choice points back to a requirement or a number from earlier. If you can say where each box came from, the interviewer will notice.