Building a URL Shortener: A System Design Guide

Building a URL Shortener: A System Design Guide

A URL shortener looks trivial—map a short code to a long URL and redirect. But it's a classic system design problem because the simple core hides real decisions about key generation, storage, caching, and scale. Get those right and the service handles enormous read traffic reliably; get them wrong and you hit collisions, slow redirects, or link rot.

This guide walks through designing a URL shortener from first principles: the requirements, the core data model, how to generate short codes, how to serve fast redirects, and how it all scales.

Why the design matters

The workload has a distinctive shape: writes are rare (creating a link) but reads are extremely frequent (every click). That read-heavy profile drives most of the design—especially caching and how quickly you can look up a destination.

Reliability matters too. A redirect that's slow or down breaks every link that depends on it, across every channel where it was shared. The bar for uptime and latency is high.

Requirements

Functional

• Create a short code for a given long URL.
• Redirect a short code to its long URL.
• Optionally support custom slugs, expiration, and analytics.

Non-functional

• Low latency on redirects—this is the hot path.
• High availability—downtime breaks live links everywhere.
• Scalability for read-heavy traffic.
• Durability—links must not disappear.

Key concepts

The core data model

At its heart, a shortener is a key-value mapping:

The critical index is on short_code, because that's what every redirect looks up.

Generating the short code

You have a few strategies:

• Hashing the URL (e.g., taking part of a hash). Simple, but risks collisions that must be handled.
• Base62 encoding of an incrementing ID. Turn a numeric ID into a compact string using [a-zA-Z0-9]. Guaranteed unique, no collision checks, and short. This is the common choice.
• Random string with collision check. Generate a random slug and verify it's unused. Flexible but requires a uniqueness check on write.

Base62 of an auto-incrementing ID is popular because it's collision-free by construction: each new link gets the next ID, encoded into a short string.

ID 1        -> "1"
ID 125      -> "21"
ID 999999   -> "4c91"

With 62 characters, even a 7-character code yields trillions of combinations—far more than most services will ever need.

Custom slugs

When a user requests a custom slug, you check availability and reserve it. Custom and generated slugs share the same table; the generator just skips any reserved values.

How a redirect flows, step by step

1. Request arrives. A browser requests short.domain/abcd.
2. Check the cache. Look up abcd in a fast in-memory cache first.
3. On a cache hit, redirect immediately. Return a 301/302 with the Location header.
4. On a miss, hit the database. Look up the code by its indexed key.
5. Populate the cache. Store the result so the next request is fast.
6. Log the click asynchronously. Record analytics off the hot path so it never slows the redirect.
7. Return the redirect. The browser follows the Location header to the destination.

The design principle here: keep the redirect path as short and cached as possible, and push everything non-essential (like analytics writes) off to the side.

Best practices

• Cache aggressively. Redirects are read-heavy and highly cacheable. An in-memory or edge cache handles the vast majority of lookups.
• Index on the short code. It's the lookup key for every redirect; the index must be fast.
• Log analytics asynchronously. Never let a click-tracking write block the redirect.
• Choose the redirect type deliberately. A 301 is cacheable and passes SEO value but is sticky; a 302 keeps you free to change destinations. Many services default to 302.
• Push redirects to the edge. Serving from locations near users cuts latency dramatically.
• Plan for durability. Replicate storage so a link never vanishes.
• Handle expiration cleanly. Check expires_at on read and return a clear response for expired links.

Tip: Because a 301 is aggressively cached by browsers and intermediaries, changing a destination after issuing 301s is hard. If a link's destination might change, prefer a 302.

Common mistakes to avoid

• Ignoring collisions with hashing. If you hash to generate codes, you must handle collisions—base62 of an ID sidesteps this entirely.
• Synchronous analytics writes. Logging clicks inline adds latency to every redirect. Do it asynchronously.
• No caching layer. Hitting the database on every redirect wastes the read-heavy profile's biggest optimization.
• Defaulting to 301 blindly. Its caching makes destination changes painful; choose based on whether links need to stay editable.
• Unindexed lookups. A missing index turns fast redirects into slow scans.
• Single point of failure. Without replication and redundancy, one outage breaks every link.

Real-world considerations

• Scale of reads. A popular service serves far more reads than writes; the architecture should optimize the read path above all.
• Rate limiting. Protect the create endpoint from abuse with rate limiting.
• Security. Scan destinations for malicious URLs to avoid becoming a phishing vector.
• Analytics pipeline. Stream click events to a separate store so reporting never competes with redirects.
• Custom domains. Supporting custom domains means resolving the incoming host as well as the slug.

Frequently asked questions

Why is base62 encoding common for short codes?

It converts a numeric ID into a compact, URL-safe string using 62 characters, producing unique codes with no collision checks and keeping them short.

Should I use a 301 or 302 redirect?

Use 301 for permanent moves where you want caching and SEO value to pass; use 302 when the destination might change, since 301s are aggressively cached and hard to update.

How do you make redirects fast?

Cache the lookups (in memory and at the edge), index the short code, and keep non-essential work like analytics off the redirect path.

How do you prevent short-code collisions?

Encoding an incrementing ID with base62 guarantees uniqueness by construction. If you hash or randomize instead, you must check for and resolve collisions on write.

How is analytics logged without slowing redirects?

By writing click events asynchronously—queuing them for a separate pipeline rather than blocking the redirect response.

How does the service scale for high traffic?

By optimizing the read-heavy path: heavy caching, edge distribution, indexed lookups, and replicated, durable storage.

Conclusion

A URL shortener is a small idea with real engineering depth. The core is a key-value map from short code to long URL, but the interesting decisions live in how you generate codes (base62 of an ID for collision-free simplicity), how you serve redirects (cache first, index always, log async), and how you scale the read-heavy path (edge and memory caching, replication).

Design for the traffic shape—rare writes, frequent reads—and the service becomes fast, reliable, and effectively boring in the best possible way.

Try ZipZy

Want a shortener that's already engineered for fast, reliable redirects? Create branded short links with built-in analytics and custom domain support. Start free.

Keep learning: Caching Strategies for Fast Redirects · Rate Limiting with Atomic MySQL Upserts · How Link Redirects Work (301 vs 302)