URL Shortener

Shorten, redirect, count. Explore the read path, the write path, ID generation, and what breaks when one link goes viral.

New URLs: 100M / month · ~40 writes/s avg · ~400/s peak
Redirects: 10B / month · ~4,000 reads/s · 100:1 read:write
Storage: 500 bytes / record · ~50 GB new per month
Key space: base62, 7 chars · 62^7 ≈ 3.5T keys

Client

The browser or app that asks for a short link and later follows one. Its first step is a DNS lookup for the short domain, which happens before any connection to the edge is opened.

CDN Edge

DNS first resolves the short domain to an anycast address, and the client then connects to the nearest edge. The edge terminates TLS and serves hot redirects from its cache before origin sees them.

DNS / L7 LB

Origin entry: DNS steers the edge to a healthy region, and the L7 load balancer spreads requests across stateless app servers, pulling any that fail health checks.

App servers

Stateless servers that run both paths: redirect (cache, then shard lookup) and shorten (claim an ID from KGS, write the row, write through the cache, prime or purge the CDN).

Redis Cluster

Holds the hot short-key to long-URL mappings so most redirects never touch Postgres. Keys route to nodes by hash slot.

Postgres shards

The source of truth for every link. Rows are sharded by hash of the short key, so a redirect lookup goes to exactly one shard.

DB replicas

Each shard streams its WAL to replicas. One replica acknowledges synchronously so an acknowledged link survives a primary loss, and it can be promoted.

KGS

Key Generation Service. Hands out unique IDs (or whole ranges of them) so app servers can mint 7-character base62 keys without coordinating per write.

Analytics

Counts clicks without ever being on the redirect's critical path. Events flow asynchronously to a queue and a warehouse.