Design a Distributed URL Shortener with High-Throughput Redirection
We want to design a web service that takes a long URL and generates a unique, compact short URL. When a user navigates to the short URL, they must be redirected instantly to the original long URL. The system needs to support custom aliases and basic analytics tracking for click counts without adding latency to the critical redirect path.
- Generate a unique 6 to 7 character short alias for any given valid long URL.
- Redirect users from the short URL to the original long URL via HTTP 301 or 302.
- Support optional user-defined custom short aliases.
- Increment aggregate click counters for analytics asynchronously.
- Extremely low latency for redirection under 20ms globally.
- High availability for the redirect endpoint (99.99%).
- Durability of URL mappings preventing data loss.
- Scalability to handle read spikes without degrading database health.
100 million new URLs shortened per month. 10 billion redirections per month, translating to roughly 4,000 writes per second and 40,000 reads per second at peak.
- High-level architecture diagram showing clients, load balancers, application servers, caches, and persistent stores.
- Data model schema design specifying primary keys, indexes, and partitioning keys.
- URL shortening algorithm and ID generation strategy explanation.
- Caching and traffic management strategy for handling read hot-spots.
Shows a clear mechanism for generating short, unique keys (such as pre-generated offline token ranges, distributed counter translation, or cryptographic hashing with collision resolution) without single-point bottlenecks.
Places an in-memory cache (like Redis or Memcached) in front of the database for read-heavy paths, addressing cache eviction policies and hot-key mitigation.
Selects an appropriate database store (NoSQL or relational) and defines a clean schema using the short hash as the primary access key for O(1) lookups.
Demonstrates that click tracking and analytics logging are offloaded asynchronously via message queues or event logs so they do not block the critical redirection path.
Explains the trade-offs between HTTP 301 (Permanent) and 302 (Temporary) redirects regarding browser caching, analytics accuracy, and server load.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Follow-up: How would you modify your id generation and caching strategy if one specific short link suddenly went viral and started receiving 100,000 requests per second?
Assume high read-to-write ratios (100:1). Short hashes must be collision-resistant and compact (e.g., 7 characters). Redirect latency must be kept under 20 milliseconds globally.
- Views
- 11