Design a URL Shortener

Requirements to pin down first

• Functional: create a short link for a long URL, redirect a short link to the original, optional custom alias and expiry, basic click counts.
• Non-functional: redirects must be fast (p99 under 50 ms at the server) and highly available; short codes must be unique and not guessable in sequence; links last for years.
• Out of scope unless asked: user accounts, detailed analytics dashboards, link editing.

Capacity estimates

Two conclusions follow. Write load is tiny, so one well-provisioned database could handle it; the real work is serving reads fast. And 7 characters gives more than 500 times the codes we need for five years, so we never need to worry about running out.

API

POST /api/v1/links
  body: { "longUrl": "https://...", "alias": "spring-sale", "expiresAt": "2027-01-01" }
  201 -> { "shortUrl": "https://sho.rt/spring-sale", "code": "spring-sale" }
  409 if the alias is taken

GET /{code}
  301 or 302 with Location: <longUrl>
  404 if unknown, 410 if expired

Data model

A single table, links(code PK, long_url, created_at, expires_at, owner_id), covers the core. Because every redirect is a primary-key lookup, a key-value store such as DynamoDB or Cassandra fits naturally, though Postgres with the code as primary key works perfectly well at 3 TB with sharding by code once it outgrows one node. Click counts go to a separate pipeline, never into the hot redirect row.

Generating short codes

The cleanest approach is to give each link a unique 64-bit integer and base62-encode it. To avoid a single counter bottleneck, each app server leases a block of IDs, for example 10,000 at a time, from a small coordinator table or ZooKeeper, and hands them out from memory. To keep codes from being sequential and guessable, run the integer through a reversible permutation (a simple Feistel network or multiply-by-a-large-odd-number modulo 62^7) before encoding.

static final String ALPHABET =
    "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";

static String encode(long id) {
    if (id == 0) return "0";
    StringBuilder sb = new StringBuilder();
    while (id > 0) {
        sb.append(ALPHABET.charAt((int) (id % 62)));
        id /= 62;
    }
    return sb.reverse().toString();   // e.g. 125 -> "21"
}

The alternative, hashing the long URL with MD5 and taking the first 7 characters, needs a collision check on every insert (read, then conditional write) and gives the same code to everyone who shortens the same URL, which breaks per-user analytics. Mention it, then explain why the counter approach is simpler.

Components

301 or 302?

A 301 Moved Permanently lets browsers and proxies cache the redirect, which cuts load and latency, but repeat clicks then never reach your server, so analytics undercount and you cannot change the destination later. A 302 Found keeps every click flowing through the service. Bitly-style products that sell analytics generally use 301 with short cache headers or 302; the important thing is to state the trade-off and choose deliberately. More on cache layers in caching.

Common mistakes in interviews

• Spending ten minutes on the hash function and never estimating traffic.
• Incrementing a click counter on the link row during each redirect, turning a cheap read into a contended write.
• Forgetting abuse: malicious URLs need scanning against a blocklist, and creation endpoints need rate limits.
• Ignoring custom alias collisions with generated codes; reserve a separate namespace or check both.
• Not handling expired links, which should be lazily rejected on read and cleaned up by a background job.

Interview questions