Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.
• Add posibility to add cutom name for url

Non-Functional Requirements:

1. High availability — The service must be highly available (uptime > 99.9%). Broken short links are a terrible user experience.
2. Low redirect latency — Redirects must complete in < 100ms. Users clicking a link expect instant navigation.
3. Highly scalable — The system should handle millions of URLs and billions of redirects, scaling horizontally as traffic grows.
4. High Reliability - The system is supposed to have well thought out observability so I know about errors and can observe performance

API Design

POST urlshortener.com/create

Request:

body: {

"link" : https://example.com

"custom": mylink

}

Response:

body: {

"link" : https://urlshortener.com/

}

Ex:

1. https://urlshortener.com/ef92b778
2. https://urlshortener.com/customlink

GET urlshortener.com/

Request:

https://urlshortener.com/ef92b778

https://urlshortener.com/customlink

High-Level Design

Request comes through load balancer which gives us good scalability in situation whew we need to handle more load, so when we need to scale a server.

Application server is a server which gonna to handle traffic and save and get data from the database.

Redis will improve our database health, so if there are people who have multiple urls shortened, or there are organisation which use multiple urls we can take advantage of that

Prometheus is giving us metric on which we can act upon

Detailed Component Design

Application Server contains 3 services that handle the core logic:

1. Shortener Service (Write Path)

• Request comes in → validate URL (not empty, valid format)
• Generate SHA-256 hash of the URL, take last 8 characters
• Try saving to DB. If collision → add epoch + salt, re-hash, retry until successful
• Save mapping: {short_hash → long_url} to the database

2. Redirect Service (Read Path)

• Extract hash from the short URL
• Lookup in Redis cache first
• Cache hit → return 301 Redirect immediately
• Cache miss → query database → return redirect → populate cache

3. ID Generator

• Generates unique short codes using hash + salt
• Ensures no two URLs map to the same alias

Caching Strategy

• CDN caches 301 redirect responses at edge — handles viral links without hitting origin
• Redis caches URL mappings for fast lookups (reduces DB load)
• On cache miss → fallback to database

Monitoring

• Prometheus provides metrics (request rate, latency, error rate, cache hit ratio)
• Alerts trigger auto-scaling or manual intervention

Partitioning

PostgreSQL native hash partitioning distributes data across 10 partitions:

CREATE TABLE url_mappings ( short_hash TEXT PRIMARY KEY, long_url TEXT NOT NULL, created_at TIMESTAMP) PARTITION BY HASH (short_hash);

• short_hash (9-char string) is hashed internally → hash % 10 → picks the right partition
• No application-level logic needed — PostgreSQL routes queries automatically
• No additional indexes needed — primary key on short_hash has maximum cardinality and the only query is WHERE short_hash = ?
• Each partition holds ~1/10th of total rows, keeping indexes small and lookups fast
• Easily scalable — add more partitions as data grows (e.g., from 10 → 20)

Why hash partitioning works here: Every redirect query includes the short hash, so each lookup hits exactly one partition — no scatter queries across all shards.