Loading system design…
Loading system design...
Design a URL shortening service like TinyURL or Bitly that takes long URLs and generates short, unique aliases that redirect to the original URLs.
| Metric | Value |
|---|---|
| New URLs created | 100 million / month (~40 per second) |
| Redirects served | 10 billion / month (~4,000 per second) |
| Read-to-write ratio | 100:1 |
| Average URL length | 200 bytes |
| Storage per entry | ~500 bytes (URL + metadata) |
| Short code length | 7 characters (Base62 → 62⁷ ≈ 3.5 trillion unique codes) |
| Storage for 5 years | 100M × 12 × 5 × 500B ≈ 3 TB |
| Cache (20% hot URLs) | ~600 GB Redis |
Given a long URL, generate a unique, short alias (e.g., https://tiny.url/a1B2c3)
When a user accesses the short URL, redirect them (HTTP 301/302) to the original long URL
Allow users to optionally choose a custom short alias (e.g., tiny.url/my-brand)
Short URLs should expire after a configurable TTL; default is no expiry
Track click analytics per short URL: total clicks, unique visitors, geographic breakdown, referrer, device/browser
Provide an API for programmatic URL creation, deletion, and analytics retrieval
Support rate limiting per user/API key to prevent abuse
Detect and block malicious/phishing URLs at creation time
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In