shortenUrl()
redirectUrl()
Entry layer: A load balancer (or API gateway) sits at the edge of the system. It handles secure connections (TLS termination), distributes incoming requests across multiple server instances, and routes traffic to the right service: POST /shorten goes to the Shortener Service, GET /{shortCode} goes to the Redirect Service.
Write path (shorten URL): The Shortener Service receives the long URL, asks the ID Generation Service for a unique identifier, and stores the mapping shortCode → longURL in the database as a key-value record. The short URL (e.g., tinyurl.com/abc123) is returned to the client.
Read path (redirect): The Redirect Service handles GET /{shortCode}. It first checks the Redis cache:
The client receives a 302 Found response with the long URL in the Location header, and the browser redirects to the destination.
Identifier generation: A strategy exists to generate unique short codes and avoid collisions (details such as the specific encoding/algorithm are covered in the component design).
Storage layer: The database stores the shortCode → longURL mapping; Redis caches recently accessed mappings for fast reads.
Caching layer: Redis acts as a hot-read cache to serve frequent redirects without hitting the database.
Shortener service will receive long url, and will generate short random string as shortened url, it will return to user as something like https://bit.ly/asHao9
After returning the short url, shortener service will input that to redis for faster access
| Column | Type | Notes |
id | BIGINT / UUID | primary key |
short_code | VARCHAR(7–10) | unique — what the client requests |
long_url | TEXT | destination |
created_at | TIMESTAMP | |
expires_at | TIMESTAMP | nullable — needed if URLs expire |