GoogleSystem DesignHard
Design a URL Shortener (like bit.ly)
System DesignURL ShortenerDatabaseScalability
Question
How would you design a URL shortener service like bit.ly? Discuss the system architecture, database design, and scalability considerations.
Interview Answer
Design a service with two core APIs (shorten and redirect), unique short-code generation, persistent URL mapping storage, and caching for hot keys. Scale horizontally with load balancing and shard strategy.
Explanation
Start with requirements (latency, availability, throughput), then API contract, schema, code generation strategy (Base62/counter/hash), and read path optimization with Redis cache. Discuss bottlenecks: hot keys, key collisions, abuse, and analytics write amplification.
Key Points
- Separate write path (shorten) and read path (redirect)
- Use unique indexed short_code column
- Cache hot short codes to reduce DB hits
- Plan for rate limiting, abuse prevention, and observability
Common Mistakes
- Ignoring short-code collision strategy
- No cache invalidation or TTL policy
- Missing discussion on analytics/event pipeline
Likely Follow-Up Questions
- How would you handle custom aliases and expiration?
- How do you prevent abuse and malicious URL redirection?
- How would you support geo-based low-latency redirects?
Interview Timing
Target speaking time: about 7 minutes.