URL Shortener System Design: Interview Guide (2026)

Why Everyone Asks This Question

"Design a URL shortener" (like Bitly or TinyURL) is one of the most common system design interview questions. It looks tiny: turn a long link into sho.rt/aB3x9Kq. But it touches everything interviewers care about: capacity estimates, unique ID generation, database choice, caching and trade-offs.

This guide walks through it the way you'd answer in an interview, step by step.

🎯 Quick Answer (30-Second Read)

• Two APIs: create a short link (write) and redirect (read). Reads dominate, often 100:1.
• Short code = base62 (a–z, A–Z, 0–9). 7 characters give 62⁷ ≈ 3.5 trillion codes.
• Generate codes from unique IDs (a counter or ID ranges per server) encoded in base62, instead of hashing and checking for collisions.
• Store code → long URL in a key-value friendly database. Cache popular codes in Redis.
• Redirect with 302 if you need click analytics; 301 lets browsers cache it.

Step 1: Requirements

Step 2: Capacity Estimates

Interviewers want to see you reason with numbers. Assume:

The math:

• Writes: 100M / (30 × 24 × 3600 s) ≈ 40 per second
• Reads: 40 × 100 ≈ 4,000 redirects per second (plan for peaks several times higher)
• Total links: 100M × 12 × 5 = 6 billion
• Storage: 6B × 500 bytes ≈ 3 TB

Conclusion: storage is modest, writes are light, and the system is read-heavy. That points to caching as the main performance lever.

Step 3: How Long Should the Code Be?

With base62, each character has 62 options:

6 billion links fit in 6 characters, but 7 leaves huge headroom and makes codes harder to guess.

Step 4: Generating Unique Codes

Making counters work at scale: a central ID service hands each app server a range (server 1 gets 1–1,000,000, server 2 gets 1,000,001–2,000,000). Servers assign IDs from their range in memory and only ask for a new range when it runs out. Ranges can be coordinated with a database sequence or a tool like ZooKeeper.

ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"

def to_base62(n: int) -> str:
    code = ""
    while n:
        n, r = divmod(n, 62)
        code = ALPHABET[r] + code
    return code or "0"

print(to_base62(125_000_000_000))   # → '2crtgcg' (7 characters)

Step 5: Architecture

Redirect flow:

Step 6: Database Choice

The core data is a simple key → value lookup with no joins: code → long_url, created_at, expires_at, user_id.

• Key-value / wide-column stores (DynamoDB, Cassandra) scale this pattern easily.
• Postgres or MySQL also work well at this size (3 TB) with an index on the code, plus read replicas or sharding by code later.

Either is defensible in an interview. Explain your reasoning.

Step 7: 301 vs 302 Redirects

Services that sell analytics usually use 302 (or 307).

Extras Interviewers Like

• Custom aliases: check availability, reserve in the same table
• Expiry: store expires_at, check on redirect, clean up in the background
• Abuse: rate-limit creation, scan destinations for malware or phishing
• Analytics: send click events to a queue so redirects stay fast
• Availability: replicate the database and run servers in multiple zones

Frequently Asked Questions

Conclusion

A URL shortener is small but complete: estimate capacity, choose base62 codes of the right length, generate them from unique IDs, store a simple key-value mapping, cache aggressively for a read-heavy workload, and pick 301 or 302 based on whether you need analytics. Explaining those trade-offs is exactly what interviewers want to hear.

Sources

• MDN: HTTP redirections (301, 302, 307, 308)
• Redis: Caching solutions

Last verified: 14 October 2026.

Related reads: Rate Limiter Explained · Consistent Hashing Explained · Redis Explained · Instagram System Design

I write about system design and how real products are built. Follow on LinkedIn or X, or invite me to speak.