URL Shortener System Design – How TinyURL and Bitly Work at Scale DWP | SDWP

URL shorteners like TinyURL and Bitly look simple on the surface. You give them a long URL, and they return a short one. But behind this simplicity lies a well-designed distributed system that handles massive traffic, high availability, and low latency.

This problem is one of the most frequently asked system design questions in interviews at companies like Amazon, Google, Uber, and Flipkart. It is also one of the best topics to understand core system design concepts such as hashing, databases, caching, load balancing, and scalability.

In this article, we’ll design a URL shortener step by step, starting from requirements and ending with a scalable production-ready architecture.

Understanding the Problem

A URL shortener converts a long URL like

https://www.example.com/articles/system-design/url-shortener-complete-guide

into a short URL like

https://tiny.url/aZ3kL9

When a user opens the short URL, the system should redirect them to the original long URL instantly.

At scale, this system needs to handle millions of requests per day with very low latency.

Functional Requirements

The system should generate a unique short URL for a given long URL.

When a user accesses the short URL, they should be redirected to the original URL.

The system should support a very large number of URLs.

Optionally, the system may support custom aliases and link expiration.

Non-Functional Requirements

The system should be highly available.

Redirection should be extremely fast (low latency).

The system should be horizontally scalable.

The system should be reliable and fault tolerant.

Assumptions

We expect millions of read requests and fewer write requests.

Short URL length should be as small as possible.

Most traffic will be read-heavy.

High-Level API Design

To shorten a URL

POST /shorten

Request: longUrl

Response: shortUrl

To redirect

GET /{shortCode}

Response: HTTP 301 or 302 redirect to longUrl

Basic Database Design

At the core, we need a mapping between a short code and a long URL.

Table: url_mapping

Columns

id (primary key)
short_code (unique)

long_url

created_at

expiry_time (optional)

Choosing the Right Database

Since this is a simple key-value lookup system, both SQL and NoSQL can work.

However, for large-scale systems

NoSQL databases like DynamoDB or Cassandra are preferred for fast reads.

SQL databases can still work with proper indexing and sharding.

In most interviews, a key-value store is a solid choice.

How to Generate the Short URL

This is the most important part of the design.

Approach 1: Hashing the URL

We can hash the long URL using algorithms like MD5 or SHA and take the first few characters.

Pros

Simple to implement.

Cons

Collision handling becomes complex.

Approach 2: Base62 Encoding (Preferred)

This is the most common approach used in real systems.

Steps

Generate a unique numeric ID (auto-increment or distributed ID).

Convert the ID into Base62.

Use the Base62 string as the short URL.

Base62 uses

a–z, A–Z, 0–9

This allows us to generate billions of unique short URLs with very small length.

Why Base62 is Preferred

It avoids collisions.

It generates short, readable URLs.

It scales extremely well.

Redirection Flow

When a user opens a short URL

The request hits the load balancer.

The application server extracts the short code.

The system looks up the short code in cache.

If found, redirect immediately.

If not found, fetch from database, update cache, then redirect.

Caching Strategy (Very Important)

Since redirection is read-heavy, caching is critical.

We use Redis or Memcached to store

short_code → long_url

Benefits

Reduces database load.

Improves response time dramatically.

Cache eviction can be based on

LRU (Least Recently Used)
TTL (Time to Live)

Load Balancing

Multiple application servers sit behind a load balancer.

The load balancer distributes incoming requests evenly, ensuring

High availability

Fault tolerance

Horizontal scalability

Stateless application servers make scaling easy.

Handling Scale (Millions of Requests)

To support massive scale

Use horizontal scaling for app servers.

Use database sharding based on short_code or ID range.

Add read replicas for databases if needed.

Use CDN for faster global access if required.

Handling Collisions and Failures

With Base62 encoding, collisions are avoided.

If a cache fails, the database acts as a fallback.

If one app server fails, traffic is routed to others.

Link Expiration and Analytics (Optional Features)

You can add

Expiry time for short URLs.

Click count analytics.

User-specific dashboards.

These are usually stored in separate tables or analytics systems to avoid impacting the core redirection flow.

HTTP 301 vs 302 Redirect

301 (Permanent Redirect):

Used when the URL mapping will never change.

302 (Temporary Redirect):

Used when tracking clicks or supporting expiration.

Most real systems use 302 to allow flexibility.

Common Interview Follow-up Questions

How do you prevent duplicate URLs?

You can store a hash of the long URL and reuse existing mappings.

What happens if Redis goes down?

The database becomes the source of truth.

How many URLs can you support with Base62?

With 7 characters, you can support billions of URLs.

Final Architecture Summary (Textual)

Client

→ Load Balancer

→ Application Server

→ Cache (Redis)
→ Database (Key-Value Store)

→ Redirect Response

Final Thoughts

URL Shortener System Design is the perfect problem to demonstrate your understanding of real-world scalable systems. It combines simplicity with depth and allows interviewers to evaluate how well you think about performance, scalability, and reliability.

If you can explain this system clearly, you are already operating at a strong system design level.

System design with Piyush

Building strong foundations for interviews and real-world systems.