Design a URL shortener

A short link is seven characters of text. Someone drops it into a WhatsApp group, the group forwards it twice, and by dinner half a million people have opened it. Behind those seven characters is a service that does exactly one thing: take a code, find a URL, send the browser there.

That is why it opens so many interviews. There is nowhere to hide. Get the code wrong and two people walk away with the same link. Get the read path wrong and your database falls over at a tenth of the traffic you just promised to handle.

The order below is the order to use in the room. Ask, count, draw, then defend.

Step 1: Understand the problem#

The worst opening move is drawing a box. Spend the first three minutes asking questions instead, because every answer moves a line in the design you are about to draw.

Here are the six that earn their time, with the replies you will usually get and what each one settles.

Not one of those questions was about technology, and that is the point. You now know the read ratio, the code length, the failure mode that matters, and where the servers live.

What you are building, and what you cut#

Say the cuts out loud. An unstated cut reads as something you forgot.

Back of the envelope#

Drag these. The point is not the default answer, it is watching which decision each input controls.

Step 2: Propose the high level design#

The API#

Four endpoints. Each one has a single decision in it worth defending.

{
  "longUrl": "https://indgeek.com/learn/hld/design-a-url-shortener",
  "customAlias": null,
  "expiresAt": "2031-08-25T00:00:00Z"
}

The data model#

One table carries the entire product.

There is no auto increment id here on purpose. It would cost 8 bytes across 180 billion rows and buy you nothing, because nothing ever looks a row up by it.

Clicks do not belong in this table either. One row per click turns a system doing about 1,200 writes a second into one doing 116,000, and it drops a write into the path of every redirect. Clicks get their own pipeline, further down.

The whole system on one whiteboard#

Figure 1 is the design, at the level of detail you would actually draw in 45 minutes. Two paths share a front door and then have almost nothing in common. Creates run across the top and are allowed to be slow. Redirects run across the bottom and are not.

Walking Figure 1 in order:

1. Every request enters at the load balancer, which terminates TLS and rate limits by caller. Creates are the expensive request, so the limit lives here rather than in your application code.
2. A create goes to the create tier. It is stateless and small: 1,200 requests a second across three hosts is nothing.
3. The host needs an id and does not ask the database for one. It takes the next id from a block of 1,000 it reserved earlier. That block is the subject of the first deep dive.
4. The ID range service is the only thing touching the counter row, and it touches it about once a second for the whole fleet.
5. The create writes the row, then writes the same entry straight into Redis so the very first click is already warm.
6. A redirect goes to the redirect tier, which is stateless and much bigger. Nothing here remembers anything, so you scale it by adding hosts and you deploy a copy of it in every region you serve.
7. The host reads Redis. About 99 requests in 100 end here, in roughly a millisecond, and the user gets a 302.
8. On a miss it reads the database, backfills Redis, and returns. A miss is the only time this system touches a disk. If the code does not exist at all, that is a 404 from the same lookup.
9. The click is published to an event log and the response goes out immediately. Nothing downstream can make a user wait.
10. The aggregator rolls raw events into one minute windows.
11. Those windows land in a columnar store, which is what a dashboard would read.
12. A nightly sweeper clears rows past their expiry. The live path never scans for expired links, it just stops finding them.

Notice what is missing. No queue in the redirect path. No service mesh. No search index. Every box in Figure 1 is there because a number from the napkin math put it there, and you should be able to name that number for each one.

Boxes and arrows show you what exists. They do not show you who waits for whom, and that is the thing an interviewer is listening for. Figure 2 is the create path in the order it actually happens. Press play, or step through it.

Step 3: Design deep dive#

Where the short code comes from#

This is the part interviewers push on, and the part most answers get wrong.

The tempting approach is to hash the long URL, take the first seven base62 characters and call it done. It fails twice over. Two people shortening the same URL usually want two different links, because they want separate click counts. And truncated hashes collide: in 62^7 slots a collision becomes likely somewhere around a few million links, which you will pass on day one. You can check the table and retry, but now every create is a read plus a write, and the retry rate climbs as the table fills.

Random codes have the same problem in a nicer suit. Fine while the table is empty, quietly worse forever after.

The approach that holds up never looks at the table at all. Figure 3 steps through it.

Be honest about what the scramble buys you. It hides the sequence from a casual observer, and anyone who collects a handful of codes and does some algebra can reverse it. If the requirement is that links must be unguessable by a motivated attacker, you need real random bits and the collision check that comes with them. Say that trade out loud rather than letting the interviewer find it.

Custom aliases skip this machinery entirely. The user supplies the code, you insert it, and the primary key either accepts it or throws a duplicate key error you turn into a 409. No lookup first, because a lookup then an insert is a race between two users typing the same alias at the same moment.

The read path, and the one key that ruins it#

The redirect is a cache lookup and little else. Cache aside, a one day TTL, and the entry written into Redis at create time so even the first click is a hit. At a 99% hit ratio the database sees about 1,200 reads a second, which one primary and one replica handle without noticing.

Figure 4 is one click, end to end. The last two messages are the ones people forget, and they are the whole argument for a 302.

All of that holds right up until a single link goes viral. Now the traffic is not spread across millions of keys. It is 400,000 requests a second for one key, and one key lives on exactly one Redis shard. Adding shards does not help. The shard that owns the key sits at 100% CPU while the other eleven idle.

The fix is unglamorous and it works: cache the hottest entries in the memory of the redirect process itself, with a TTL of one second. A viral link is then served out of a local hash map. One second of staleness on a link created hours ago is not a problem anybody has, and Redis drops from 400,000 requests a second on that key to one per host per second.

You will watch that break, and then get repaired, under Break it below.

Counting clicks without slowing the redirect#

Every redirect wants to record an event. Do it synchronously and the user waits on a write before they get their 302, and a clicks table taking 116,000 writes a second sits directly in front of your most important request.

So do not do it synchronously.

The trade you are making: if a redirect host dies with events still in its buffer, those clicks are gone. For a click counter, losing a handful in a crash is fine, and saying so is a stronger answer than pretending durability is free. If the question were payments instead of clicks, the answer flips, and the write goes into the request path where it belongs.

Break it#

Drag the traffic up. Watch which box goes first, and read why it was that one.

The repair takes one box and about forty lines of code.

Trade-offs#

Interview replay#

Checkpoint#