URL Shortener System Design Walkthrough
Complete design walkthrough with animated diagrams, capacity math, API design, schema, and failure modes.
Solution PathTarget: 25 min
We designed a URL shortener for 500M DAU with counter-based ID generation using range pre-allocation (62^7 = 3.5 trillion codes, zero collisions, 96-year runway). Redis caching at 95%+ hit ratio absorbs 275K of the 289K read RPS. MySQL InnoDB sharded by short_code across 16 shards handles 29K write RPS with strong consistency. Kafka decouples click analytics from the sub-50ms redirect hot path.
1/10
1.
What is URL Shortener?
A URL shortener maps long URLs to short, shareable codes. A 120-character link like https://example.com/products/category/item?ref=campaign becomes a clean 7-character code like bit.ly/3xK9mPq.
The redirect takes under 50ms. Bitly processes 10 billion clicks per month across 500 million short links. The system sounds simple, but the real challenge is generating unique codes across distributed servers at 29K writes/sec without collisions.
If two servers both produce code "abc1234" for different URLs, one redirect silently points to the wrong destination. No error, no retry, no recovery.
That makes collision-free ID generation the hardest problem in this design.
A 120-character URL becomes 7 characters. Bitly handles 10B redirects/month, each in under 50ms. The real challenge: collision-free ID generation across distributed servers at 29K writes/sec.
A URL shortener takes a long URL and generates a shorter alias that redirects to the original destination. When users click the short link, the service redirects them to the original URL. Services like Bitly and TinyURL process billions of clicks per month. The system sounds simple, but the real challenge is generating globally unique short codes at scale (29K writes/second) with zero collisions while maintaining sub-50ms redirect latency for 289K reads/second.
- Why 7 characters? Because 62^7 = 3.5 trillion codes, enough for 95+ years at 100M URLs/day
- 10:1 read-to-write ratio means we design a cache-first architecture, not a database-first one
- We chose counter-based ID generation with range pre-allocation over hashing because counters guarantee uniqueness by construction with zero retries
- This is the most commonly asked system design question at FAANG. Master it and the patterns (caching, sharding, ID generation) transfer to half the other topics