← CatZep/Engineering Guides/System Design/Foundations

Designing a URL Shortener

A system design walkthrough for building a service like TinyURL or bit.ly: how a long URL becomes a short slug, how that slug is stored and looked up, and why almost every decision is shaped by the fact that reads vastly outnumber writes.

A URL shortener takes a long, unwieldy link and hands back a short one — https://example.com/abc123 — that redirects to the original. The product is deceptively simple, which is exactly why it is a popular interview question: the requirements are small enough to fully specify in a few minutes, yet the design forces you to reason about ID generation, storage schemas, caching, and the semantics of HTTP redirects. This guide walks the problem from requirements to a working design, keeping the discussion generic and educational rather than tied to any one company's implementation.

Concepts to understand first

Each definition includes a concrete example and the condition under which the mechanism is useful. You can read this guide without opening another guide.

1. Requirements and Estimates

Before sketching anything, pin down what the service must do. The functional requirements are short: given a long URL, return a short URL; given a short URL, redirect the caller to the original long URL. Optional extras — custom aliases, link expiry, analytics, user accounts — are worth naming so you can decide what is in scope, but the core is just those two operations.

The non-functional requirements are where the design gets its shape. The system should be highly available (a dead redirect breaks every link that was ever shared), redirects should be low-latency, and short URLs must not be guessable in a way that leaks others' links. The single most important observation, though, is the traffic shape.

A quick back-of-the-envelope pass: 100M writes per month is roughly 40 writes per second on average. At a 100:1 ratio that is about 4,000 reads per second, with peaks well above that. Storage is modest per row — about 500 bytes for the long URL plus metadata — so 100M rows a month is about 50 GB a month, 0.6 TB a year, and 6 TB over ten years. That fits a small sharded key-value store (or a few replicated database servers) comfortably. The dominant cost is not storage; it is serving the read flood quickly and reliably.

Clarifying questions worth asking before you commit: Can users pick custom aliases? Do links expire? Can a link be edited or deleted? Do we need click analytics? Should the same long URL always return the same short URL? How short must the slug be?

Estimation, step by step

The 20% cache rule comes from the 80/20 rule: a small share of links gets most clicks. 33 GB fits in memory on one or two cache servers.

2. API Design

POST /api/v1/urls
  body:    {"long_url": "https://example.com/very/long/path", "alias": "optional", "expires_at": "optional"}
  returns: 201 {"short_url": "https://sho.rt/abc123"}
           400 invalid URL, 409 alias taken, 429 too many requests

GET /{slug}
  returns: 301 or 302 with header  Location: https://example.com/very/long/path
           404 unknown slug, 410 expired or deleted

3. Write Path and Read Path

The service has exactly two flows, and it pays to draw them separately because they are asymmetric. The write path runs rarely and can afford to do real work; the read path runs constantly and must be as short as possible.

On a create request, the service generates an identifier for the new link, encodes that identifier into a short slug using base62, confirms the slug is not already taken (a check that is trivial or unnecessary depending on the ID strategy below), stores the mapping, and returns the assembled short URL to the caller. This is the expensive path, but it runs only on the order of tens of times per second.

On a redirect request — a GET /abc123 — the service extracts the slug, looks up the corresponding long URL, and responds with an HTTP redirect pointing at it. The browser then follows that redirect to the destination. If the slug does not exist, the service returns 404 Not Found. The lookup checks an in-memory cache first and only touches the database on a miss. Keeping this path to a single fast lookup is the entire performance game.

4. Two Ways to Generate the ID

Separate code uniqueness from unguessability. A unique sequence or correctly allocated Snowflake ID encoded in base62 is compact but enumerable. For public unguessable links, generate sufficiently long slugs with a cryptographically secure random generator and atomically insert under a unique constraint. Unguessability does not replace access control for private resources.

Seven fixed base62 characters provide 62^7≈3.52×10^12 possibilities. Uniform random samples can collide long before the space is full; at n samples, expected colliding pairs are approximately n(n−1)/(2M). Handle conflicts at insert, cap retries, and monitor occupancy. Taking the leading characters of a variable-width base62 hash string is not necessarily a uniform fixed-width slug generator.

Hashing the long URL does not make the service stateless: collision handling, expiry, ownership, aliases, and stored mappings are still state. Deduplication by destination must be scoped and evaluated for privacy. An ad-hoc small Feistel permutation is not an authorization/security proof; use reviewed cryptography if that is truly required.

5. Base62 and the Length Math

Fix one case-sensitive alphabet and validate inputs. Base62 is a representation of an integer, not encryption. With alphabet 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ, 125 becomes 21.

ALPHABET = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'

def encode(n):
    if not isinstance(n, int) or isinstance(n, bool) or n < 0:
        raise ValueError('nonnegative integer required')
    if n == 0:
        return '0'
    digits = []
    # Invariant: emitted reversed digits plus remaining n encode the input.
    # Bound: n strictly decreases while positive.
    while n:
        n, remainder = divmod(n, 62)
        digits.append(ALPHABET[remainder])
    return ''.join(reversed(digits))

def decode(code):
    if not code or len(code) > 32:
        raise ValueError('nonempty bounded code required')
    n = 0
    for char in code:
        n = n * 62 + ALPHABET.index(char)  # invalid symbols raise ValueError
    return n

assert encode(125) == '21' and decode('21') == 125

Leading zeroes decode to the same number; reject noncanonical encodings if the API requires one representation. A full nonnegative signed 63-bit ID may need 11 characters, so a seven-character limit also constrains the allocator.

6. Data Model

The storage need is a single mapping from slug to long URL, which is about as simple as a schema gets. A relational table or a key-value store both work; the access pattern (look up by slug) is a primary-key read either way.

The write step is therefore a single insert: create a new row carrying the id, the shortURL slug, and the longURL destination (plus any optional metadata). Because the redirect path looks up by slug, the shortURL column carries a unique index so the lookup is an indexed point read rather than a scan.

# create: one row insert
INSERT INTO urls (id, shortURL, longURL, created_at)
VALUES (9326731923, 'abc123', 'https://example.com/some/very/long/path', now());

# redirect: indexed point lookup
SELECT longURL FROM urls WHERE shortURL = 'abc123';

7. Redirect Semantics: 301 vs 302

301 is a permanent redirect and may be cached; 302 is temporary but can also be cached under explicit headers. Choose Cache-Control deliberately for expiry, revocation, target mutability, and analytics. Neither status alone guarantees every click returns to this service.

301 is a permanent redirect and may be cached; 302 is temporary but can also be cached under explicit headers. Choose Cache-Control deliberately for expiry, revocation, target mutability, and analytics. Neither status alone guarantees every click returns to this service.

8. Caching the Hot Slugs

Size the cache from unique hot mappings, not redirect request count: resident keys × measured bytes per entry, plus metadata/allocator overhead, replicas, and headroom. A 20% share of daily requests is not automatically 20% of distinct keys or a universal Pareto law.

Cache mapping metadata, including expiry/disabled state and version, with a documented maximum stale-serving policy. DB-first invalidation still has delayed-fill races; version/invalidation fences are needed for stronger guarantees. Negative lookups need a short TTL and create-time invalidation. Ensure a newly published slug is readable on the selected replica path before returning success.

For mutable, revocable, or analytics-sensitive destinations, choose redirect and Cache-Control policies deliberately. Permanent client caches cannot reliably be recalled by purging your own Redis/CDN entries. Validate destination schemes (usually HTTP/HTTPS); any server-side scanning/fetching also needs SSRF protections for resolved addresses and every redirect.

9. Failure Modes

10. Tradeoffs

Worked example: an enumerable code and a cached redirect

A unique counter and a random slug solve different problems.

Run a small, testable model

Download concepts.py. It uses only the Python 3.10+ standard library. From the directory where you saved it, run:

python3 concepts.py encoding
python3 concepts.py test

The model round-trips integers, rejects negative/invalid input, and shows why base62 is not encryption.

The program contains deterministic assertions and failure traces. It is a learning model, not a production service: it does not implement network consensus, distributed durability, authentication, or third-party delivery. Read its contracts and try changing an input before extending it.

11. A 45-Minute Interview Walkthrough

12. Common Mistakes

• Base62-encoding a 64-bit Snowflake id and calling it 7 characters. It is 11.
• Check-then-insert without atomicity. Two writers can claim the same slug.
• Treating hash collisions as rare. At a billion links, 7-character prefixes collide hundreds of thousands of times.
• Choosing 301 and then promising analytics. Cached redirects never reach you.
• Doing analytics writes on the redirect path. Log the click to a queue and return the redirect at once.

13. Summary

The URL shortener is a small system whose design follows almost entirely from one fact — reads dominate writes — and a couple of clean encoding choices.

14. Check Yourself

1. At 100M new links a month, how many 6-character base62 slugs are left after 10 years?
   Answer

   62⁶ ≈ 56.8 billion, minus 12 billion used, leaves about 44.8 billion. Six characters would last about 47 years.

2. What is encode(125) in base62 with alphabet 0-9a-zA-Z?
   Answer

   125 = 2 × 62 + 1, so the digits are 2 and 1: "21".

3. Why does a counter-based slug need no collision check, while a hash-based slug does?
   Answer

   Base62 is a one-to-one map from integers to strings, and every counter value is used once. A 7-character hash prefix squeezes a huge input space into 3.5 trillion values, so different URLs can land on the same prefix.

4. Marketing wants a click count for every link. Which redirect code do you use, and what does it cost?
   Answer

   301 is a permanent redirect and may be cached; 302 is temporary but can also be cached under explicit headers. Choose Cache-Control deliberately for expiry, revocation, target mutability, and analytics. Neither status alone guarantees every click returns to this service.

5. An app server that leased ids 5,001–6,000 crashes after using 200. What happens?
   Answer

   Ids 5,201–6,000 are never used. That is fine: slugs only need to be unique, not gap-free.

6. How would you stop people from guessing other users' links?
   Answer

   Scramble the counter value with a secret one-to-one permutation (for example a Feistel network) before base62, or add random characters. Also rate limit lookups of unknown slugs.

15. Key Terms

Slug

The short code at the end of the short URL.

Base62

A reversible representation of a nonnegative integer using 62 symbols, typically digits and upper/lowercase letters. Repeated division by 62 emits the digits; decoding multiplies the accumulator by 62 and adds each digit. Example and limits above.

301 / 302

Permanent and temporary HTTP redirects.

Location header

The response header that holds the redirect target.

Range allocation

Leasing a block of ids so servers rarely coordinate.

Birthday paradox

Random values start colliding after about the square root of the space.

Feistel network

A reversible way to shuffle numbers with a secret key.

LRU cache

A cache that evicts the least recently used entry first.

16. Further Reading

• Alex Xu, System Design Interview, Vol. 1, chapter “Design a URL Shortener”.
• RFC 9110, HTTP Semantics, section 15.4 (the 3xx redirect codes, including 301, 302, 307 and 308).
• RFC 9111, HTTP Caching (how browsers decide to cache responses).
• MDN Web Docs, “Redirections in HTTP”.