Design a URL Shortener

You paste a long link and get back something like sho.rt/008sudj. Anyone who opens the short link lands on the long one. It looks like a weekend project, which is why interviewers like it: a small surface hides a read-heavy workload, an ID scheme that has to work across many servers, a cache that does most of the work, and a database that must never lose a row.

This case study follows the same steps as A Framework for Any Design. Try each "Your turn" box before you read on. The point is to practise the thinking, not to memorise this answer.

#Clarify the problem

The prompt is one sentence on purpose. The interviewer wants to see whether you pin down the scope before drawing boxes. Ask about features first, then scale, then what matters most when things go wrong.

Write the result down where the interviewer can see it:

• Functional: create a short link for a long URL, with an optional custom alias and expiry; redirect a short code to its long URL; count clicks per link.
• Non-functional: redirects are fast (under 20 ms added) and highly available; created links are never lost; codes are short.
• Out of scope: user accounts, abuse scanning, analytics dashboards.

#Estimate the scale

Turn the interviewer's numbers into per-second rates and bytes. A month has about 30 × 86,400 ≈ 2.6 million seconds.

• Writes: 100 million ÷ 2.6 million ≈ 40 links a second on average. Assume peaks of 5x: 200 a second.
• Reads: 100 × 40 = 4,000 redirects a second on average, 20,000 at peak.
• Code length: with 62 characters (0-9, a-z, A-Z), 6 characters give 62⁶ ≈ 57 billion codes and 7 give 62⁷ ≈ 3.5 trillion. Five years of links is 6 billion, so 7 characters leave plenty of room.

Two more numbers shape the design. Each redirect response is about 500 bytes, so even 20,000 a second is only 10 MB/s of traffic. And if the hottest 10 million links get most clicks, caching them takes 10⁷ × 500 B = 5 GB of memory, which fits on one cache node.

#Define the API

POST /api/links
  body: { "long_url": "https://...", "alias": "spring-sale"?, "expires_at": "2027-01-01"? }
  201 Created   { "code": "008sudj", "short_url": "https://sho.rt/008sudj" }
  400 Bad Request   the URL is not valid
  409 Conflict      the alias is taken
 
GET /{code}
  302 Found   Location: https://the-long-url...
  404 Not Found     no such code, or it has expired

The redirect status is a real decision. A 301 (moved permanently) lets browsers cache the redirect, so repeat clicks never reach you: less load, but you cannot count those clicks or change the target later. A 302 (found) is not cached, so every click comes through. We need click counts, so use 302 and accept the extra traffic, which the estimate says is small.

Protect POST with a per-client rate limit; a shortener without one becomes a free tool for spammers within days.

#Model the data

code        CHAR(7)   PRIMARY KEY   -- "008sudj" or a custom alias
long_url    TEXT                    -- up to 2 KB
created_at  TIMESTAMP
expires_at  TIMESTAMP NULL
clicks      BIGINT                  -- updated in batches, not per click

The only query on the hot path is a lookup by primary key. There are no joins, no range scans, and rows never change after they are written (except the click count). A key-value or wide-column store (such as DynamoDB or Cassandra) fits this well: it partitions by key out of the box, which we will want at 3 TB and beyond. A relational database also works at this size, with read replicas; say so, and say you would pick it if the team already runs one. What matters is the reason: single-key reads, no joins, easy partitioning by code.

Custom aliases live in the same table. Because code is the primary key, "insert if absent" makes alias claims safe: two users racing for spring-sale cannot both win.

#High-level design

Redirects outnumber creates 100 to 1, so they get their own service and their own cache. Creating a link needs a code that no other server will hand out; a small ID allocator gives each create server a block of numbers to use.

Step through creating a link, then opening it twice.

#Deep dives

Interviewers push on two or three parts. For this question it is almost always how codes are made, how redirects stay fast, and how clicks are counted without slowing redirects.

#Generating short codes

Every server must hand out codes that no other server hands out, without a slow check on each request.

The arithmetic behind the random option: with 6 billion links stored and 3.5 trillion possible codes, a new random code collides with probability 6 × 10⁹ ÷ 3.5 × 10¹² ≈ 0.2%. One retry in 500 creates is fine. If an interviewer worries about guessable codes from the counter, keep the counter and scramble the number with a reversible function before encoding: still no collisions, no longer sequential.

#Keeping redirects fast

Clicks are lopsided: a few links get most of the traffic. A cache in front of the store, with LRU eviction, serves most redirects in about a millisecond. Because a link never changes after it is created, there is no invalidation problem on writes. Deletes and expiry are the exceptions: delete the cache key when a link is deleted, and check expires_at on every redirect so an expired link is never served from cache. The caching lesson covers stampedes, which matter here when a link goes viral.

#Counting clicks without slowing redirects

Updating a counter row on every click would put a write on the hot path, and a viral link would make one row the hottest spot in the database. Instead, the redirect service publishes a small click event to a queue and returns immediately. A worker reads the events, adds them up per code, and writes one update per link every few seconds.

The trade-off to say out loud: counts lag by a few seconds, and if the queue loses events, counts are slightly low. For click counts that is fine. For billing per click it would not be, and you would make the events durable and processing idempotent.

#Bottlenecks and failures

At 10x the traffic (200,000 redirects a second at peak, 30 TB over five years), the redirect servers scale by adding more, since they hold no state. The cache becomes a cluster, split by consistent hashing so adding a node moves only a small share of keys. The store is partitioned by code, which spreads evenly because codes are spread evenly. The allocator barely notices: blocks of 1,000 at 2,000 writes a second is 2 requests a second.

#What a strong answer sounds like

Every level gets to a working design. What differs is how much of it is driven by the numbers and how the trade-offs are argued.

#Follow-up questions

#How would you run this in several regions?

Serve redirects from every region with a local cache and a local replica of the store; replication lag only delays brand-new links by a second or two. Give each region its own ID ranges so creates never coordinate across regions.

#The same long URL is submitted twice. Same code?

Not by default. Deduplication needs an index on the long URL and lets one user's expiry or deletion affect another's link. Offer it per user if asked.

#How do you stop abuse?

Rate limit creates per API key and per IP, check new URLs against a blocklist, and scan them asynchronously so a bad link can be disabled after the fact.

#How do you delete a link quickly?

Mark it deleted in the store and delete the cache key. Because redirects use 302, browsers have not cached it, so the next click sees the change.

#What if one link gets a million clicks a minute?

That is about 17,000 a second on one key. Keep a copy in each redirect server's memory for a few seconds so the cache node holding it is not overloaded.