Designing a Distributed High-Throughput URL Shortener (Bitly / TinyURL)
Design a high-availability URL shortening service capable of sub-10ms redirection latency using Base62 encoding, distributed unique ID generation (Twitter Snowflake), and multi-tier Redis caching.
Functional Requirements
- •Generate unique 7-character short URL from long URL
- •Redirect short URL (301 / 302 redirect) to long destination
- •Custom aliases and click analytics
Non-Functional Requirements
- •99.999% availability
- •Ultra-low redirection latency (<10ms)
- •Zero hash collisions
Capacity & Scale Estimation
Core Architectural Components
1Distributed ID Generator (Snowflake)
Generates 64-bit globally unique sequential IDs without database coordination using timestamp + worker ID + sequence bits.
2Base62 Encoding Module
Converts numeric 64-bit ID into a 7-character Base62 string (62^7 = 3.52 Trillion unique URLs).
3Multi-Tier Cache (Redis Cluster)
Caches the top 20% most frequently accessed URLs (80/20 rule) in RAM to serve 95%+ of redirects in <2ms.
4Distributed NoSQL / SQL Store
DynamoDB / PostgreSQL partitioned by ShortKey for permanent URL mapping persistence.
Architectural FAQs & Interview Deep Dives
Should URL shorteners return HTTP 301 or 302 redirects?
Use 302 (Found / Temporary) if you need to track real-time click telemetry on every request. Use 301 (Moved Permanently) to allow browsers to cache redirects locally and reduce server load.
Why is Base62 encoding preferred over MD5/SHA-256 hashing?
Cryptographic hashes produce long strings (32-64 chars) requiring truncation and complex collision handling. Base62 of a unique 64-bit ID guarantees zero collisions with exact 7-character length.