Cheat sheet
URL Shortener — 5-minute cheat sheet
URL Shortener — 5-minute cheat sheet
Requirements
- Create short URL from long URL (with optional alias)
- Redirect short → long
- Optional analytics: click counts, geo, referrers
- Read-heavy: ~100:1 read:write
Estimation formula
peak_qps = DAU × requests_per_user × peak_multiplier / 86400 · storage_gb = new_urls_per_day × row_size_bytes × retention_days / 1e9
API skeleton
POST /urls { long_url, alias?, ttl? } → { short_url, short_code, expires_at }
GET /{short_code} → 302 Location: <long_url>
GET /urls/{short_code}/stats → { clicks_total, clicks_7d, top_referrers } [auth]High-level sketch
Client → CDN → LB → URL Service → Redis → (miss) → DB. Click events → Kafka → OLAP store.
Top-3 trade-offs
- 301 vs 302 (browser cache vs analytics accuracy)
- Random vs counter-based short codes (simplicity vs no collisions)
- Sync vs async click ingestion (latency vs event loss under failure)
Top-3 failures
- Redis outage → cache stampede on DB. Mitigate: circuit breaker, load shed.
- Primary DB failover → 30s write outage. Mitigate: synchronous replica.
- Region outage (at extreme scale) → Anycast reroutes; capacity slack absorbs.
Interview soundbite (60s)
"At 10K RPS, one Postgres does the job. At 100K we add Redis and read replicas. At 1M we shard writes and push analytics async through Kafka. At 1B, the redirect completes at the edge — origin only sees cache misses and writes — and storage is a globally replicated KV with quorum writes for the create-then-share hot path."