How would you design a URL shortener like bit.ly?

A URL shortener converts a long URL to a short unique key (e.g., bit.ly/abc123) and redirects users. Requirements: functional: shorten URL, redirect short URL, custom aliases, expiry; non-functional: low latency reads, high availability, ~100M URLs/day. Scale estimation: 100M writes/day = ~1200 writes/sec; assume 10:1 read:write = 12,000 reads/sec; 100M URLs × 500 bytes = 50GB/day storage. URL shortening algorithm: Option 1: hash (MD5/SHA-256) → take first 7 chars → collision possible; Option 2: Base62 encoding of an auto-increment ID (62 chars: a-z, A-Z, 0-9) — 7 chars = 62^7 ≈ 3.5 trillion unique URLs. Better: distributed ID generator (Twitter Snowflake — time-based 64-bit IDs ensuring uniqueness and sortability without coordination). Database: schema: (short_url, original_url, created_at, expires_at, user_id); SQL or NoSQL (DynamoDB — simple key-value pattern). Redirection: 301 (permanent, browser caches — saves server load but can't track clicks) vs 302 (temporary, no browser cache — allows click tracking). Use 302 for analytics. Cache: cache popular short URLs in Redis (80/20 rule — 20% of URLs get 80% of traffic). Cache size: 20% of 100M = 20M URLs × 500 bytes ≈ 10GB. Architecture: client → load balancer → app servers (stateless) → Redis cache → SQL DB; ID generation service (centralized or per-region); CDN for assets.