Loading...
| ID | Requirement |
| ----- | ------------------------------------------------------------------------------------------------------------------- |
| FR-01 | The system shall accept a valid long URL from the user. |
| FR-02 | The system shall validate the URL before creating a short URL. |
| FR-03 | The system shall generate a unique short code for each URL. |
| FR-04 | The system shall return the generated short URL to the user. |
| FR-05 | When a user accesses the short URL, the system shall redirect the user to the original long URL. |
| FR-06 | The system shall store the mapping between the short code and the original URL. |
| FR-07 | The system shall prevent accidental short-code collisions. |
| FR-08 | The system shall support expiration of short URLs if an expiration period is configured. |
| FR-09 | The system shall allow users to optionally create a custom short code, if supported. |
| FR-10 | The system shall return an appropriate error for invalid, expired, or non-existent short URLs. |
| FR-11 | The system may track usage statistics such as number of clicks, timestamp, and referrer, if analytics are required. |
| FR-12 | The system shall provide an API for creating and resolving short URLs if it is implemented as a REST service. |
| ID | Requirement |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| NFR-01 — Performance | URL creation should typically complete within **200 ms** under normal load. |
| NFR-02 — Redirect Latency | Short-URL redirection should typically complete within **100 ms** excluding network latency. |
| NFR-03 — Scalability | The system should support a large and growing number of URLs and redirect requests without significant performance degradation. |
| NFR-04 — Availability | The service should target high availability, for example **99.9% or higher**. |
| NFR-05 — Reliability | The system shall reliably maintain the mapping between short codes and original URLs without data loss. |
| NFR-06 — Security | The system shall validate and sanitize URLs to protect against malicious or unsafe URLs and abuse. |
| NFR-07 — Uniqueness | Generated short codes must be unique within the system. |
| NFR-08 — Maintainability | The system should use modular components so URL generation, storage, redirection, and analytics can be independently maintained. |
| NFR-09 — Observability | The system should provide logging, metrics, and monitoring for URL creation, redirection, errors, and system health. |
| NFR-10 — Data Durability | URL mappings should survive application restarts and infrastructure failures according to the defined recovery objectives. |
| NFR-11 — Rate Limiting | The system should limit excessive URL creation and redirect requests to prevent abuse and denial-of-service attacks. |
| NFR-12 — Compatibility | The generated short URLs should work across commonly used browsers and devices.
Assuming 100M URLs created per month and 10 redirects per URL, we need roughly 40 write QPS and 400 read QPS on average, with a 5× peak giving approximately 200 write QPS and 2,000 read QPS. Storage would be around 3 TB for five years, or roughly 5–10 TB including indexes and replication.
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
| API | Purpose |
| ------------------------------------ | ------------------------------- |
| `POST /api/v1/urls` | Create short URL |
| `GET /{shortCode}` | Redirect to original URL |
| `GET /api/v1/urls/{shortCode}` | Get URL details |
| `DELETE /api/v1/urls/{shortCode}` | Disable short URL |
| `GET /api/v1/urls/{shortCode}/stats` | Get click statistics — optional |
Client/User – Creates and accesses short URLs.
Load Balancer – Distributes requests across application servers.
URL Shortener Service – Validates URLs, generates unique short codes, stores mappings, and handles redirects.
Redis Cache – Provides fast lookup of Short Code → Long URL.
URL Database – Permanently stores URL mappings and metadata.
Message Queue – Processes click/analytics events asynchronously.
Analytics Service – Processes URL usage and click statistics.
Analytics Database – Stores analytics data.
Monitoring & Logging – Tracks errors, performance, traffic, and system health.
short_code PK
long_url
created_at
expiration_date
status
user_id
| Component | How It Works | Scaling | Capacity | Key Tradeoffs |
| ------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| **URL Shortener Service** | Validates URL, generates unique **Base62 short code**, stores mapping, handles redirects | Stateless instances behind Load Balancer; horizontal scaling | ~40 write QPS average, ~200 peak; ~386 read QPS average, ~2,000 peak | Sequential ID is simple but predictable; random IDs are harder to guess but require collision checks |
| **Redis Cache** | Stores `Short Code → Long URL`; cache hit returns URL immediately; cache miss queries DB | Redis Cluster, partitioning, replication | Designed to handle ~2,000 peak redirect QPS and reduce DB reads | Higher TTL improves hit rate but uses more memory and may retain stale data |
| **URL Database** | Permanently stores short code, long URL, timestamps, expiration, status, user ID | Read replicas, replication, sharding/partitioning when needed | ~100M URLs/month; ~3 TB raw storage over 5 years | SQL provides consistency and indexing; NoSQL offers easier horizontal scaling |