URL Shortener

i. Requirements

Functional

• Given a long URL, generate a short URL (alias)
• Given a short URL, redirect to the original long URL
• Short URLs should be unique and not collide
• Optional: custom aliases, expiration dates, analytics

Non-Functional

• High availability — redirects must always work
• Low latency — redirect < 10 ms p99
• Durability — short URLs should not disappear
• Read-heavy: ~100:1 read/write ratio

Out of Scope

• User authentication
• Full analytics dashboard
• Link preview / safety scanning

ii. Capacity Estimates

Per-tier sizing — back of the envelope

At staff level, the interesting math is not the headline QPS — it is how that QPS distributes across tiers once cache hits absorb the bulk.

iii. High-Level Design

Client
  │
  ▼
[Geo-DNS / Anycast]  ──▶  [CDN Edge PoP]  ──hit──▶  302
  │ miss
  ▼
[Regional Load Balancer]
  │                     │
  ▼                     ▼
[Write Service]      [Redirect Service]  ──▶  [In-process LRU (L1)]
  │                     │                        │ miss
  │                     ▼                        ▼
[ZK/etcd range]      [Redis Cluster (L2)]  ──miss──▶  [DB Read Replica]
  │                     ▲                                      │
  ▼                     │ async fill / invalidate              │
[DB Primary]  ──────────┴──────────────────────────────────────┘
  │
  ▼ async
[Kafka]  ──▶  [Analytics OLAP]   |   [Replication → other regions]

Four caching layers sit between a redirect request and the database: browser cache (when using 301), CDN edge, in-process LRU on the redirect pod, then Redis. By the time a request reaches the database, three independent caches have agreed they do not know the answer — which itself is a useful signal (the URL is either cold or non-existent).

Write path

1. Client POSTs long URL
2. Write service calls token generator → gets a unique short code
3. Writes {short_code → long_url, created_at, expiry} to DB primary
4. Optionally pre-warms cache
5. Returns short URL to client

Read path (redirect)

1. Client GETs tinyurl.com/abc123
2. Redirect service checks Redis cache first
3. Cache hit → 301/302 redirect immediately
4. Cache miss → query DB read replica → cache the result → redirect

Cache is not a database with worse durability. It is a different shape of correctness.

iv. Key Design Decisions

Short Code Length

• Alphabet: base62 = [a-z A-Z 0-9] = 62 characters
• 7-character code: 62⁷ ≈ 3.5 trillion unique codes
• At 100M/day: covers ~95 years before exhaustion
• 6 characters = 56 billion → only ~1.5 years. Use 7.

Token Generation Strategy

See patterns/token-generation for all approaches. For URL shortener:

Chosen: Zookeeper-coordinated counter ranges

• Each write server claims a range of counter values from Zookeeper (e.g., server A gets 1–1M)
• Convert counter value to base62 → short code
• Servers generate tokens locally within their range — zero DB coordination overhead
• When range exhausted, claim new range from Zookeeper

Why not MD5/SHA hash?

Hash of URL → take first 7 chars → collision risk + not human-stable. Same URL hashed twice = same code (good for dedup but complicates custom aliases).

Why not UUID?

128 bits → need to shorten anyway; introduces randomness we don't need.

301 vs 302 Redirect

Database Choice

See patterns/database-selection for the full decision framework. The access pattern here is almost the textbook case for a wide-column store: a single equality lookup on a high-cardinality key, no joins, no range scans on the hot path, and a write that never updates an existing row.

Schema — Cassandra

CREATE TABLE urls (
  short_code   text PRIMARY KEY,
  long_url     text,
  user_id      bigint,
  created_at   timestamp,
  expires_at   timestamp,
  is_custom    boolean,
  is_disabled  boolean   -- soft-delete tombstone for abuse takedowns
) WITH compaction = {'class':'LeveledCompactionStrategy'}
  AND default_time_to_live = 0
  AND gc_grace_seconds = 864000;

short_code is the partition key — every redirect is a single-partition read, the cheapest operation Cassandra offers. Leveled compaction is chosen over Size-Tiered because reads are random and we want bounded read amplification (≤ ~10 SSTables touched per query in steady state).

Replication & consistency

• Replication factor: RF = 3 per region, deployed across three availability zones
• Write consistency: LOCAL_QUORUM (2 of 3) — survives a single-AZ outage without losing write availability
• Read consistency: LOCAL_ONE on the redirect path — minimal latency, eventual is acceptable for an idempotent redirect
• Read consistency for custom alias availability check: LOCAL_SERIAL via lightweight transaction (LWT, Paxos-backed) — prevents two users grabbing the same custom alias under a race
• Cross-region: async multi-DC replication; do not require EACH_QUORUM on the hot path or you will inherit cross-region RTT (~150 ms)

Secondary access — queries by user_id

Cassandra's golden rule: one table per query pattern. Do not use a secondary index on user_id at scale — it scatter-gathers across nodes and degrades non-linearly. Instead, denormalize:

CREATE TABLE urls_by_user (
  user_id     bigint,
  created_at  timestamp,
  short_code  text,
  long_url    text,
  PRIMARY KEY ((user_id), created_at, short_code)
) WITH CLUSTERING ORDER BY (created_at DESC);

Both tables are written in the write path. The cost is ~2× write amplification, which is fine — writes are 1% of traffic. The benefit is that "list my links" becomes a single-partition range read.

Postgres alternative — when it's enough

• Single-region, < ~500M rows, write QPS < ~5K sustained
• Index short_code with a hash index (Postgres 10+) or BTREE; BTREE wins if you ever want range scans
• Partition the urls table by created_at month for cheap expiration cleanup (DROP PARTITION instead of DELETE)
• Streaming replication to 5–10 read replicas; route reads with a connection-pool-level read/write split (pgbouncer + a router)

Caching

See patterns/caching for full strategies. The right framing for this system is not "add a cache" but "build a four-layer cache hierarchy where each layer absorbs an order of magnitude more traffic than the next."

• Strategy: Cache-aside on read path. On miss, the pod (not Redis) reads the DB and writes to L3; L2 is populated naturally by the same pod over its next requests
• Cache key: url:{short_code} → long_url. Keep values small (< 2 KB); store metadata as a separate meta:{short_code} key only if expiry/disabled checks are needed
• TTL: min(24h, expires_at - now) with ±10% jitter to avoid synchronized expiry storms
• Eviction: Redis allkeys-lru (approximate LRU); never run Redis at 100% memory — set maxmemory with ~20% headroom
• Negative caching: 404s are cached too — url:{code} = "__MISS__" with a 60 s TTL. Without this, enumeration attacks (or a single bad QR scan) can repeatedly punch through to the DB
• Bloom filter: A short-code-existence bloom filter (sized for 1B keys with 1% FPR → ~1.2 GB) sits in front of the DB. Membership check is ~150 ns. Most non-existent codes never reach Redis or DB at all
• Stampede protection: Per-key in-process singleflight (Go-style request coalescing) so 10K concurrent misses on the same key become one DB read. Stack a Redis-side mutex (SET NX EX 5s) when the in-process layer can't help (cross-pod misses)
• Stale-while-revalidate: On the CDN layer, serve the stale URL while async-refetching the origin. Acceptable because URL→long_url is functionally immutable for the life of a code

v. Deep Dives

Custom Aliases

• User specifies tinyurl.com/my-brand
• Write service checks availability first (SELECT on short_code)
• Reserve these in same table; mark is_custom = true
• Risk: squatting → rate-limit custom alias creation

URL Expiration

• Store expires_at in DB
• Redirect service checks expiry before returning URL
• Background job (cron) deletes/tombstones expired records
• Cache TTL should be min(24h, expires_at - now)

Analytics (if in scope)

• Write click events asynchronously to Kafka
• Downstream consumer aggregates into ClickHouse or similar OLAP store
• Never block the redirect on analytics writes

vi. Bottlenecks by Tier

Every system has a binding constraint. The interesting question at staff level is not "is this fast?" but "which tier saturates first, and what does it take to lift that ceiling?" Below is the redirect path ceiling at each layer with realistic single-instance numbers, and what you do when you hit them.

vii. Hot Keys & Viral URLs

A Super Bowl ad goes live with tinyurl.com/sb-ad. Within 30 seconds that one short code accounts for 10M hits/min — 90% of total system traffic on a single key. This is the classic hot key problem, and it is the single failure mode most likely to bring a URL shortener down in production.

Why it hurts

• The Redis shard owning that key sees all of the L3 traffic for that key on one CPU core (Redis is single-threaded)
• If the L2 in-process cache misses on a fresh pod, the new pod hammers Redis for the same key during the warm-up window
• The DB shard owning that key takes the same disproportionate load on any cache miss

Mitigations — layered

1. CDN absorbs the brunt. A correctly configured CDN sees one origin pull per PoP per TTL window. At ~300 PoPs and a 5-minute TTL, the origin sees ~3,600 pulls/hour for a hot URL regardless of how viral it gets
2. In-process LRU with long TTL. A 100K-entry LRU per pod means a viral key sits permanently in memory after the first request. Use Caffeine (Java), Ristretto (Go), or moka (Rust) — admission-based caches resist scan pollution
3. Key splitting (hot key sharding). Maintain N replicas of the hot key in Redis (url:abc:0 … url:abc:9) and route requests by request hash. Spreads single-key load across N shards. Implement only after detection — most keys don't need this
4. Read from any replica. In Cassandra, LOCAL_ONE reads can land on any of the RF=3 replicas — three nodes serve the single hot partition concurrently. Add replicas (RF=5) for known-viral campaigns
5. Hot key detection. Sample 1% of requests, count by short_code in a sliding window (count-min sketch in Redis or in-memory). When a code exceeds a threshold (e.g., 1K QPS to origin), auto-promote it to in-process LRU with infinite TTL and increase CDN TTL via API
6. Pre-warming. For known campaigns (Super Bowl, product launch), the customer can request pre-warming — the system pushes the entry into every pod's L2 and Redis before the campaign starts

viii. Multi-Region Architecture

A global URL shortener cannot serve every redirect from one region — a request from Tokyo to a US-East origin pays ~150 ms RTT before the first byte. The interesting design question is what is regional-local vs globally coordinated.

Routing

• Geo-DNS or anycast routes the user to the nearest regional cluster. AWS Global Accelerator / CloudFront, GCP Cloud Load Balancing, or DNS-based (Route53 latency routing)
• Redirect path is region-local. A US user resolves to the US region, hits the US CDN, US Redis, US Cassandra replica. Zero cross-region traffic on the hot path

Write replication

• Cassandra multi-DC with NetworkTopologyStrategy: writes commit at LOCAL_QUORUM in the originating region; async replication to other DCs with typical propagation < 1 s
• Consequence: a user in Mumbai creating a short URL and immediately scanning the QR from Tokyo may briefly hit "not found" on Tokyo's replica. Acceptable for > 99.99% of cases; rare edge case is handled below
• Read-your-writes on the same region is guaranteed because the user's session is sticky to one region; cross-region read-your-writes is not promised

Token range coordination

• Global counter, regional ranges. A single global ZK/etcd ensemble (3 or 5 nodes, geographically diverse) is the source of truth for the next available counter block. Each region claims ranges of 1M IDs and assigns sub-ranges to local pods
• Region-prefixed ranges as an alternative: bake the region ID into high bits of the counter. Removes global coordination at the cost of slightly less compact codes
• Custom alias coordination is genuinely hard: two users in different regions could request /launch at the same time. Solve with a globally-consistent registration step — a single primary region for alias reservations, or a CRDT-friendly "first-write-wins by timestamp + region tiebreak" rule. Document the chosen semantics

RPO & RTO

ix. Failure Modes & Mitigations

The four-row table from a junior design is replaced here with a systematic walk through what breaks in production, why, and what the mitigation looks like. Group by where the failure originates.

Infrastructure failures

Data-path pathologies

Operational & deployment failures

x. Security & Abuse

A URL shortener is a redirect-as-a-service that anyone on the internet can write to. That makes it a magnet for abuse, and the abuse pathway is usually more damaging to the business than the technical failure modes. Staff-level system design accounts for this from day one.

Threat model

Takedown propagation

When abuse is detected, the URL must stop redirecting fast. The flow:

1. Set is_disabled = true in DB (single write, immediately consistent within region)
2. Publish invalidate:url:{code} to a Redis pub/sub channel — all redirect pods drop their L2 entry
3. DEL url:{code} in Redis cluster
4. Issue a CDN purge for the redirect URL via the CDN API
5. The whole flow completes in < 5 s globally; downstream redirects return a takedown page (HTTP 410 Gone, not 404)

xi. Observability & SLOs

Service-level objectives

Golden signals — per service

• Traffic: RPS at each tier (CDN, LB, app, Redis, DB); break out by region and by status code
• Errors: 4xx vs 5xx separated; 404 rate is a product metric (indicates broken or attacked codes), 5xx is a reliability metric
• Latency: p50, p99, p99.9 at each tier; latency budget allocation per tier sums to the SLO
• Saturation: CPU %, memory %, connection pool utilization, Redis memory used, Cassandra pending compactions

Key alerts

• Page on: redirect availability burn rate > 2% of monthly budget in 1 hour
• Page on: p99 latency > 50 ms for 5 minutes
• Page on: Cassandra node down (RF=3 means one more failure = data loss)
• Ticket on: any single short_code > 1K QPS (hot key candidate)
• Ticket on: Redis memory > 80% used
• Ticket on: token range claim rate > expected (indicates a pod issue or unexpected write surge)

Tracing & debugging

• Trace ID propagated through CDN → LB → app → Redis → DB so a slow request can be unwound across the stack
• Sampled tracing: 1% baseline, 100% for all 5xx and for any request > 100 ms
• Cache hit/miss as a span attribute at every layer — the trace tells you exactly where time was spent

xii. Key Takeaways

1. Read-heavy → build a four-tier cache hierarchy. CDN → in-process LRU → Redis → DB. Each tier absorbs an order of magnitude. The CDN does the heaviest lifting.
2. Base62 + counter beats hashing for uniqueness guarantees at scale. Counter ranges via ZK/etcd eliminate per-write coordination.
3. Cassandra with short_code as partition key is the textbook fit. RF=3, LOCAL_QUORUM writes, LOCAL_ONE reads, LWT only for custom alias races.
4. Cache is an optimization, never a dependency. Size the DB tier to absorb the cache-down case, or you've built a system that secretly requires every component to be healthy.
5. Hot keys are the asymmetric risk. 99.9% of keys behave; the 0.1% that go viral can saturate one Redis shard, one Cassandra partition, one anything. Layer mitigations: CDN, in-process LRU, key splitting, replica fan-out.
6. The redirect path is region-local. Anycast routing, region-local replicas, async cross-region replication. Never call across regions on the hot path.
7. Abuse is the real failure mode. Phishing scans at write time, takedown propagation in seconds, enumeration-resistant ID schemes, rate limiting at the edge.
8. Separate write and redirect services — they have completely different scaling profiles, SLOs, and failure tolerances. Don't deploy them together.
9. 301 vs 302 is a real trade-off. 301 minimizes server load and enables browser caching; 302 keeps analytics flowing. The right answer depends on your product.
10. Observability buys you the budget to ship boldly. SLOs with error budgets, golden signals at every tier, traces that span CDN to DB, and alerts that fire on burn rate — not on threshold crossings.

xiii. Go Deeper

• How would you implement URL preview (unfurl og:image) without slowing down the write path?
• Design the analytics system — how do you count unique visitors using HyperLogLog while staying under storage and privacy constraints?
• How would you migrate from Postgres to Cassandra without downtime — what's the dual-write / shadow-read plan?
• How would you implement A/B-tested redirects (one short URL → different targets per user segment) without breaking caching?
• If the system has to support 1M write QPS, what changes first — token generation, write service, or DB?
• How would you build a privacy-preserving click-analytics pipeline that still gives the URL owner useful aggregates?