Detailed Component Design

URL Generation

Approach - Auto Increment ID -> Base62 encoding

Example - ID = 125 -> "cb"

Problem: Predictable IDs

Sequencial IDs can be guessed.

Solution:

short_code = Base62(ID XOR random_salt)

Prevents enumeration attacks

Scalable Option:

Use Distributed ID Generator

timestamp + machine_id + sequence

Avoids bottleneck of single DB

CONCURRENT CREATES & COLLISION

Auto Increment ensures uniqueness

DB Gurantees atomic inserts

If using random codes

Problem: Collision Possible

Solution: UNIQUE Constraint + retry

REDIRECT Service

Flow:

Check Redis

If hit -> return

If miss -> Db lookup

Cache result

Return 301 Redirect

Why 301?

Permanent Redirect
Browser + CDN Caching
Better Performance

Cache Design (Redis)

Strategy - Cache Aside

Key Design

Key = url:{short_code}

value = long_url

Why Cache

Avoid DB Load
Reduce Latency

Failure Handling

If Redis Fails

Fallback -> DB

Production Setup

Redis Cluster (Sharding)
Replication + Failover
Eviction Policy (LRU)

DataBase Design (MYSQL)

Schema

CREATE TABLE urls (

id BIGINT PRIMARY KEY,

short_code VARCHAR(10) UNIQUE,

long_url TEXT,

created_at TIMESTAMP,

expiry TIMESTAMP

);

Optimization

Index on short_code
Read Replicas for Scaling

SCALABILITY

API Layer

Sateless Node.js Servers behind load balancers

Horizontal Scalling By adding more instances.
No session storage in server (use redis if needed)

Database Scaling

Sharding

Partition data using:

shard = hash(short_code) % N;

Each shard handles subset of data.

Read Replicas

Writes -> Primary DB

Reads -> Replica DB

Reduces read pressure.

Cache Scaling

Redis Cluster

keys distributed across multiple nodes.

Increases memory + throughput

Global Scaling

Geo-distributed deployment (multi-region)

Reduces latency for global users.

The system scales horizontally at each layer: stateless API servers, Redis Cluster for distributed caching, and database sharding with read replicas for handling large-scale traffic.

Fault Tolerance

Redis Failure

Fallback to DB
Increased Latency

Generator Failure

Multiple generator instances
Retry Mechanism

Split Brain Handling

use machine_id in ID Generation

Traffic Spikes

System should:

Rate limit users (Rate Limiting - Redis Based)

use token bucket/ sliding window

Example -

INCR user_ip

EXPIRE 1 Sec

if:

Count > 100 -> reject request

Prioritize redirects over writes

Redirects = High Priority

Shorten API = Low Priority

Under load:

Reject POST /shorten

Allow GET redirect

Load Shedding

If system overloaded:

Return:

503 Service Unavailable

Retry-After: 5 Seconds

Autoscale Servers

Scale API Servers

Scale Redis Cluster

Scale DB Replicas

BURST HANDLING + BACKOFF

Problem:

Clients retry aggressively:

1000 failed requests -> retry instantly -> system collapse

Solution: Exponential Backoff + Jitter

Example:

Retry 1 -> Wait 1 Sec

Retry 2 -> Wait 2 Sec

Retry 3 -> Wait 4 Sec

Add randomness:

Wait = base + 2^n + random(0-100ms)

Why?

Prevents thundering herd problem

Server Hint

Return: 503 + Retry+After header

Analytics (ASYNC)

Do Not Update DB Per request

Solution

Use Redis counters OR
Use queue (RabbitMQ)

Flow

Redirect -> publish event -> process async -> batch update DB

Expiry & Data Management

Expiry Strategy

Soft Delete (mark expired)
Do not reuse short codes

Scaling Data

Move expired URLs to archive table
Keep active table small

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10