Viewed
System Design
Google
Gemini 2.5 Flash
VS
Anthropic
Claude Sonnet 4.6
Design a Global URL Shortening Service
Design a public URL shortening service similar to Bitly. Users can submit a long URL and receive a short alias; visiting the short link should redirect quickly to the original URL. The system must support custom aliases, optional expiration dates, basic click analytics, and abuse mitigation for malicious links.
Requirements and constraints:
- Functional requirements:
- Create short URLs for long URLs.
- Redirect short URLs to original URLs.
- Support custom aliases when available.
- Support optional expiration time per link.
- Record click events for analytics.
- Allow users to disable a link manually.
- Scale assumptions:
- 120 million new short URLs per month.
- 1.5 billion redirects per day.
- Redirect traffic is globally distributed and read-heavy.
- Analytics data should be queryable within 15 minutes.
- Performance targets:
- Redirect p95 latency under 80 ms for most regions.
- Short-link creation p95 under 300 ms.
- 99.99% availability for redirects.
- Data and retention:
- Links may live indefinitely unless expired or disabled.
- Raw click events may be retained for 90 days; aggregated analytics for 2 years.
- Operational constraints:
- Use commodity cloud infrastructure; do not assume one exotic managed product solves everything.
- Budget matters: justify any replication, caching, and storage choices.
- Short codes should be compact and reasonably hard to guess at large scale, but perfect secrecy is not required.
In your answer, provide:
1. A high-level architecture with major components and data flow.
2. Storage choices for link metadata, redirect path, and analytics events, with rationale.
3. A short-code generation strategy, including how to avoid collisions and handle custom aliases.
4. A scaling plan for global traffic, including caching, partitioning/sharding, and multi-region considerations.
5. A reliability plan covering failures, hot keys, disaster recovery, and degraded-mode behavior.
6. Key APIs and core data models.
7. Abuse mitigation and security considerations.
8. The main trade-offs you made and why.
