Design a URL Shortener Service (Like TinyURL)

I would design a URL shortener as follows. First, requirements: create short URLs from long ones, redirect short URLs to originals with <100ms latency, support optional custom aliases, handle 100M new URLs/month with a 100:1 read/write ratio. The API has two main endpoints: POST /api/shorten {url, custom_alias?} returns the short URL, and GET /{shortCode} returns 301/302 redirect. For generating short codes, I would use a distributed ID generator (Twitter Snowflake or a counter service) and convert the numeric ID to Base62. Seven characters of Base62 give 3.5 trillion unique codes, sufficient for decades. This avoids hash collisions entirely, unlike MD5-based approaches. The database stores mappings: short_code (primary key) → original_url, created_at, user_id, expiry_date. For this scale, I would use a NoSQL database like DynamoDB for its predictable performance and easy horizontal scaling, partitioned by short_code for even distribution. Since reads dominate, I would add a Redis cache layer in front of the database. With the 80/20 rule (20% of URLs get 80% of traffic), caching hot URLs dramatically reduces database load. Cache strategy: check Redis first, on miss read from DB and populate cache with a TTL. For the redirect endpoint, I would use 301 (permanent) for SEO-friendly links and 302 (temporary) when analytics tracking is needed (301s get cached by browsers, reducing analytics accuracy). Architecture: clients → CDN/load balancer → stateless application servers → Redis cache → DynamoDB. Application servers are horizontally scalable. The ID generation service can use a Zookeeper-coordinated range allocator (each server gets a block of IDs to avoid coordination overhead). For analytics, I would asynchronously log click events to Kafka, then process with Spark for real-time and batch analytics dashboards.