Design URL Shortener
Category: system_design
Date: 2026-02-14
System Design Discussion: URL Shortener
1. Requirements (Functional + Non-functional)
Functional Requirements:
- Create short URLs for long URLs
- Support URL redirection
- Handle URL expiration (optional)
- Support analytics (optional)
Non-functional Requirements:
- High availability
- Scalability
- Low latency
- Security (prevent abuse and hacking)
2. High-Level Architecture
The high-level architecture for a URL shortener system consists of:
- Frontend: Handles user requests (Create short URL, Redirect to original URL)
- Backend: Stores and retrieves URL data, handles redirection, and analytics
- Database: Stores URL data (short URL, original URL, expiration date, etc.)
- Load Balancer: Distributes incoming traffic across multiple backend instances
- Cache: Caches frequently accessed data to reduce database load
3. Database Design
We’ll use a relational database (e.g., PostgreSQL) to store URL data.
- URL Table: stores short URL, original URL, expiration date, and creation timestamp
| Column Name |
Data Type |
Description |
| id |
int |
unique ID for the URL |
| short_url |
varchar |
short URL generated by the system |
| original_url |
varchar |
original URL |
| expiration_date |
timestamp |
expiration date for the URL (optional) |
| creation_timestamp |
timestamp |
timestamp when the URL was created |
4. Scaling Strategy
To scale the system, we can:
- Horizontal Scaling: Add more backend instances behind the load balancer to handle increased traffic
- Vertical Scaling: Increase the power of individual backend instances to handle increased traffic
- Distributed Database: Use a distributed database system (e.g., Cassandra) to store URL data across multiple nodes
5. Bottlenecks
Potential bottlenecks include:
- Database Load: Increased database load due to frequent URL creation and redirection
- Cache Invalidation: Cache invalidation due to URL expiration or changes
- Load Balancer: Load balancer becoming a bottleneck due to increased traffic
6. Trade-offs
Trade-offs include:
- Cache vs. Database: Using a cache can reduce database load but may lead to stale data if not properly invalidated
- Horizontal Scaling vs. Vertical Scaling: Horizontal scaling can provide more flexibility but may require more complex setup and management
First Principle of System Design
The first principle of system design is to “Keep it Simple, Stupid!” (KISS). This principle emphasizes the importance of simplicity and elegance in system design. In the context of the URL shortener system, we can apply this principle by:
- Using a simple database schema
- Implementing a straightforward caching strategy
- Keeping the system architecture modular and scalable
Learning Links
System Design Principles