URL Shortener System Design: How Link Shorteners Work Under the Hood

"Design a URL shortener" is one of the most popular system design interview questions — and for good reason. It touches on hashing, databases, caching, load balancing, and distributed systems, all in a deceptively simple product.

In this guide, we'll walk through how URL shorteners actually work, the key design decisions, and the trade-offs involved at scale.

A URL shortener does two things:

1. 1Shorten: Take a long URL and generate a short code
2. 2Redirect: When someone visits the short URL, redirect them to the original

Here's the high-level flow:

User creates short link:
  Long URL → Generate short code → Store mapping → Return short URL

User clicks short link:
  Short URL → Look up code → Find long URL → 301 Redirect

The core challenge is generating unique, short codes. There are several approaches:

Convert an auto-incrementing ID to a Base62 string using characters [a-zA-Z0-9]:

• ID 1 → 1
• ID 62 → 10
• ID 238,328 → ZZZ

A 7-character Base62 code supports 62^7 = 3.5 trillion unique URLs.

Pros: Simple, predictable length, no collisions Cons: Sequential IDs are predictable (users can guess other short URLs)

Apply a hash function (MD5, SHA-256) to the long URL and take the first N characters:

SHA256("https://example.com/very/long/url") → "a3f2b8c1..." Short code: "a3f2b8c"

Pros: Same input always produces the same output (deduplication) Cons: Hash collisions require handling; fixed hash length may waste space

Generate a random alphanumeric string and check for uniqueness:

Pros: Simple, unpredictable Cons: Requires collision checking on every creation; gets slower as the database fills

Most production systems use Base62 encoding with a distributed ID generator. It's simple, collision-free, and performant. At Linkly, we use a similar approach — you can read more about how URL shorteners work for a less technical overview.

The core table is straightforward:

urls ├── id (primary key, auto-increment) ├── short_code (unique index) ├── long_url (the destination) ├── created_at (timestamp) ├── user_id (who created it) └── click_count (denormalized counter)

SQL (PostgreSQL, MySQL): ACID compliance, strong consistency, good for moderate scale. Most URL shorteners start here.

NoSQL (DynamoDB, Cassandra): Better horizontal scaling for billions of URLs. Eventual consistency is acceptable for this use case.

Hybrid: SQL for URL mappings (need strong consistency for redirects), NoSQL or a time-series database for click analytics (high write volume, eventual consistency is fine).

When a user clicks a short link, the system must:

1. 1Parse the short code from the URL
2. 2Look up the corresponding long URL
3. 3Return an HTTP redirect response

• 301 (Permanent): Browser caches the redirect. Fewer server requests, but you lose visibility into repeat clicks.
• 302 (Temporary): Browser checks with the server every time. More requests, but better click tracking.

Most URL shorteners use 302 redirects for click tracking accuracy, then offer 301 as an option for SEO use cases. See our guide on 301 redirects for more on this distinction.

Redirects need to be fast — every millisecond of latency affects user experience. Caching is critical:

Cache the mapping short_code → long_url in memory:

GET /abc123 → Check Redis for "abc123" → Cache hit? Return redirect immediately → Cache miss? Query database, cache result, return redirect

A small Redis instance can cache millions of URL mappings. Since most traffic goes to a relatively small number of popular links, cache hit rates above 90% are common.

For 301 redirects, CDN edge nodes can cache the redirect response, serving it from the nearest location to the user without hitting your origin server at all.

Recording click data is a write-heavy operation that shouldn't slow down the redirect:

1. 1User clicks short link
2. 2System immediately returns the redirect
3. 3Click event is pushed to a message queue (Kafka, RabbitMQ, SQS)
4. 4A background worker processes the event: parses user agent, geolocates IP, stores analytics

This decouples the fast redirect path from the slower analytics pipeline.

• Timestamp
• IP address (for geolocation)
• User agent (for device/browser detection)
• Referrer header
• Country, city (from IP geolocation)

URL shorteners are extremely read-heavy. A typical ratio might be 100:1 reads to writes. This means:

• Optimize the redirect path above all else
• Use caching aggressively
• Read replicas for the database

If you use auto-incrementing IDs across multiple servers, you need to avoid collisions. Options:

• Snowflake IDs: Twitter's approach — embed timestamp, machine ID, and sequence number
• UUID: Universally unique but longer
• ID ranges: Assign each server a range of IDs to allocate from

Deploy redirect servers in multiple regions. A user in Tokyo shouldn't need to round-trip to a server in Virginia for a redirect.

URL shorteners can be abused for phishing and malware distribution. Production systems need:

• URL scanning — check destinations against malware and phishing databases
• Rate limiting — prevent mass creation of malicious short links
• Abuse reporting — let users report suspicious links
• Preview pages — optionally show users where a link goes before redirecting

Learn more about link safety and click fraud protection.

Beyond basic shortening and redirecting, production URL shorteners add:

• Custom domains — branded short links using your own domain
• Custom slugs — choose your own short code instead of random characters
• Expiration — time-limited links that stop working after a date
• Password protection — require a password to access the destination
• A/B testing — rotate between multiple destinations
• Geo-targeting — redirect by country
• Device targeting — different destinations for mobile vs. desktop
• QR codes — generate scannable codes for any short link

URL shortener system design is a great exercise because it starts simple but reveals layers of complexity: code generation, database design, caching, analytics pipelines, and abuse prevention. Understanding these fundamentals helps whether you're preparing for interviews or building your own tools.

Want to use a production URL shortener without building one? Get started with Linkly — all the architecture described above, ready to use with custom domains, analytics, and advanced features.