Requirements
Functional Requirements:
- Create a short URL for a given long URL.
- Return the long URL associated with a given short URL.
Non-Functional Requirements:
- List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
API Design
POST → /signup → Register a new user
POST → /signin → Login user
POST → /generateUrl → Send long URL to create short URL
GET → /getUrls → Get all URLs created by a user
GET → /:shortId → Redirect to original long URL
DELETE → /deleteUrl/:id → Delete a specific URL
PUT → /updateUrl/:id → Update long URL (optional)
High-Level Design
Frontend (Client Layer):
A web or mobile interface through which users submit long URLs, view shortened URLs, and manage their links.
API Server (Backend Layer):
Handles incoming requests such as URL shortening, redirection, and fetching user-specific URLs. It validates inputs and coordinates with other services.
URL Shortening Service:
Responsible for generating unique short codes for long URLs. Once generated, the mapping is processed and stored.
Queue / Stream (e.g., Redis Streams):
Incoming URL creation requests are pushed into a stream to enable asynchronous processing, improving scalability and handling traffic spikes.
Database (Persistent Storage):
Stores mappings of short URLs to long URLs along with user data and metadata (e.g., creation time, expiration).
Cache Layer (e.g., Redis):
Frequently accessed short URL mappings are cached to reduce database reads and improve redirection latency.
Redirection Service:
When a user accesses a short URL, the system first checks the cache; if not found, it fetches from the database and redirects to the original URL.
Detailed Component Design
there are three main components in the design, the first one is the server, its responsible for adding the url to the queue and updating the db. the second is the redis stream where all the urls will be pused. the third are the workers which will produce the short urls and then update it to the database in bulk.