Loading...
- when user request short url he/she provides long url as param and get short url as response
- when user send request to short ulr he/she automatically redirected to long url
- url maximum length 2MB (2 million characters)
- availability - high 99.99% of all time
- scalability - high up to 5000K RPS
- security - medium basic authentication
- extensibility - low
Maximum 5K RPS, no load spikes
Maximum 1K short urls per user
Maximum 1M User Base
## Create a new short url
POST /shorts
Request Body:
json
{
"url": "value"
}
```
Response Body:
{
"uuid": "cf24b8dc-197c-4c81-a9dd-28c28580b7fd",
"url": "value",
"short": "value"
}
Get details on existing short url
GET /shorts/cf24b8dc-197c-4c81-a9dd-28c28580b7fd
{
"uuid": "cf24b8dc-197c-4c81-a9dd-28c28580b7fd",
"url": "value",
"short": "value"
}
## Data model
json
{
"uuid": "cf24b8dc-197c-4c81-a9dd-28c28580b7fd",
"url": "https://codemia.io/system-design/designing-a-simple-url-shortening-service-a-tinyURL-approach",
"short": "https://somedomainname.com/cf24b8dc-197c-4c81-a9dd-28c28580b7fd"
}
```
Two-tier system with load balancing at both levels
In the API Layer (Tier 1), client requests enter through an API Server Load Balancer which distributes traffic across three API server instances for horizontal scaling and high availability.
The Data Layer (Tier 2) features a database load balancer that directs write operations to the Primary Database while routing read operations to a Read Replica, implementing a read/write split pattern.
This design provides scalability through multiple API servers, reliability through load balancing, and optimized database performance by separating read and write operations.
The separation of concerns between tiers allows each layer to scale independently according to demand.
### **Tier 1: API Layer (Presentation/Application Tier)**
The front-facing layer that handles client requests and business logic processing.
**🔄 API Server Load Balancer**
- **Purpose**: Distributes incoming client requests across multiple API server instances
- **Function**: Ensures high availability and prevents any single server from becoming overwhelmed
- **Benefits**: Provides fault tolerance and horizontal scaling capabilities
🔐 Authentication Server
Purpose: Centralized authentication and authorization service
Function: Validates user credentials, manages sessions, and handles security tokens
Integration: All API servers communicate with this service for user verification
⚡ Cache Server
Purpose: High-speed data storage for short url retrieval
Function: Reduces database load and improves response times
Types: Could be Redis, Memcached, or similar in-memory storage
Tier 2: Data Layer (Database Tier)
The persistent storage layer that manages all application data.
Components:
🔄 Database Load Balancer
Purpose: Intelligently routes database queries to appropriate database instances
Function: Separates read and write operations for optimal performance
Strategy: Implements read/write splitting for better resource utilization
💾 Primary Database
Purpose: Main database instance handling all write operations
Function: Ensures data consistency and serves as the authoritative data source
Operations: CREATE, UPDATE, DELETE operations are directed here
📖 Database Read Replica
Purpose: Secondary database instance optimized for read operations
Function: Handles SELECT queries to reduce load on the primary database
Synchronization: Stays synchronized with primary database through replication
1 Postgres Write Database + 1 read replica
32 CPU cores
30 GB memory
SSD 10TB
If main database instance fails automatic failover will promote read replica into main and switch write/read traffic to it.
Once failed database instance is recovered then automatic failover mechanism will switch back.
- add multitenant user authorization
- add premium plan with maximum 1 million urls per user