A URL shortener (like TinyURL or Bitly) is a common system design interview question because it covers API design, databases, caching, scalability, distributed systems, and consistency.

1. Requirements

Functional Requirements

Convert a long URL into a short URL.

Redirect short URL → original URL.

Custom aliases (optional).

URL expiration (optional).

Analytics (click count, location, browser).

Delete or disable URLs.

Non-Functional Requirements

High availability (99.99%)

Low latency (<100ms redirect)

Highly scalable (billions of URLs)

Durable storage

Fault tolerant

2. High-Level Design

+--------------+

User ------------->| Load Balancer|

+--------------+

|

+---------------+---------------+

| |

+--------------------+ +--------------------+

| URL Shortener API | | Redirect API |

+--------------------+ +--------------------+

| |

+---------------+---------------+

|

Cache (Redis)

|

Miss |

\/

Database (SQL/NoSQL)

|

Analytics Queue

|

Kafka / RabbitMQ

|

Analytics Workers

3. APIs

Create Short URL

POST /api/v1/shorten

Request

{

"longUrl":"https://www.google.com/search?q=system+design"

}

Response

{

"shortUrl":"https://short.ly/aZ91Kd"

}

Redirect

GET /aZ91Kd

Response

HTTP 301 Redirect

Location:

https://www.google.com/search?q=system+design

Analytics

GET /api/v1/stats/aZ91Kd

Response

{

"clicks":10231,

"countries":{

"US":4000,

"IN":3200

}

}

4. Database Design

URL Table

Field Type

short_code VARCHAR(8) PK

long_url TEXT

user_id BIGINT

created_at TIMESTAMP

expires_at TIMESTAMP

click_count BIGINT

Indexes

PK(short_code)

INDEX(user_id)

5. Short Code Generation

This is the most important part.

Option 1: Auto Increment + Base62

ID = 100

Base62(100)

=> 1C

Characters

0-9

A-Z

a-z

Total = 62

Example

1000000

↓

Base62

↓

4c92A

Pros

No collisions

Very fast

Easy

Cons

Predictable IDs

Option 2: Random String

Generate

A8zK9x

Check database

If exists

Generate again

Pros

Hard to predict

Cons

Collision possible

Option 3: Hash (MD5/SHA256)

SHA256(URL)

↓

Take first 7 chars

Problem

Different URLs may produce the same prefix (collision).

Recommended

Use

Global ID Generator

↓

Base62 Encoding

Examples

123456789

↓

8M0kX

6. Capacity Estimation

Assume

100 Million URLs/day

Each URL

Long URL = 500 bytes

Short code = 8 bytes

Metadata = 100 bytes

≈ 600 bytes

Daily storage

100M × 600

≈60GB/day

Yearly

≈22TB/year

7. Read/Write Ratio

Usually

Write : Read

1 : 100

Meaning

10M creations/day

1 Billion redirects/day

So redirect path must be heavily optimized.

8. Cache Design

Redis

Key

short_code

Value

long_url

Flow

User

↓

Redis

↓

Hit

↓

Redirect

Miss

Redis

↓

Database

↓

Redis

↓

Redirect

Cache TTL

24 Hours

Frequently accessed URLs remain in cache.

9. Redirect Flow

Browser

↓

GET /Ab91X

↓

Load Balancer

↓

API Server

↓

Redis

↓

DB (if miss)

↓

301 Redirect

10. Scaling Database

Sharding

Shard using

Hash(short_code)

Shard1

AA-AAZZ

Shard2

AB-BBZZ

...

or

hash(short_code)%N

11. Load Balancer

Multiple stateless API servers

LB

/ | \

API1 API2 API3

Easy horizontal scaling.

12. Analytics

Don't update click count synchronously.

Instead

Redirect

↓

Kafka

↓

Worker

↓

Database

Benefits

Fast redirect

Asynchronous processing

No blocking

13. Prevent Abuse

Rate limiting

CAPTCHA for anonymous users

URL validation

Malware/phishing detection

Blacklist domains

Authentication for premium features

14. Availability

Deploy across multiple availability zones.

DNS

|

Global Load Balancer

/ \

US Region Europe Region

| |

Multiple Servers

Database

Primary

↓

Replicas

Redirects can be served from replicas.

15. Bottlenecks

Problem Solution

Hot URLs Redis cache + CDN

DB overload Read replicas + caching

ID generation Distributed ID generator (e.g., Snowflake)

Analytics writes Kafka + async workers

Cache failure Database fallback

Large traffic spikes Auto-scaling

16. HTTP Status Code

301 Moved Permanently: Better for permanent URLs, allows browser/CDN caching, improves performance.

302 Found: Use if the destination may change or for temporary redirects.

Most production URL shorteners use 301 for permanent links.

17. End-to-End Flow

URL Creation

Client

│

▼

Load Balancer

│

▼

Shortener Service

│

├── Generate Unique ID

├── Base62 Encode

├── Store Mapping in DB

└── Cache Mapping (optional)

│

▼

Return Short URL

URL Redirect

Client

│

▼

GET /abc123

│

▼

Load Balancer

│

▼

Redirect Service

│

├── Lookup in Redis

│ │

│ ├── Hit → Return 301 Redirect

│ └── Miss

│

├── Lookup in Database

├── Populate Redis

├── Publish Click Event to Kafka

└── Return 301 Redirect

Key Design Decisions

Component Choice Reason

ID generation Distributed ID + Base62 Collision-free, scalable, compact

Database NoSQL (e.g., DynamoDB/Cassandra) or sharded SQL Handles billions of mappings

Cache Redis Sub-millisecond lookups for popular URLs

Redirect HTTP 301 Fast, cacheable permanent redirects

Analytics Kafka + async consumers Keeps redirect latency low

Scaling Stateless services + load balancers Horizontal scalability

Partitioning Hash-based sharding on short code Even data distribution

This design can comfortably scale to billions of URLs, millions of new URLs per day, and tens of billions of redirects while maintaining low latency and high availability.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

• API to create short url for the long url given.
• Api that accepts short url, gets corresponding large url and process requests.
• Api to know the status of the request.

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Clinet--> REST API Call (Server)--> Database

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Table :UrlpatternMatcher

column: shorturl varchar2(250)

column: Longurl varchar2(max)

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.