POST /urls
{
"longUrl": "https://example.com/very/long/url",
"expiry": "2026-06-01T00:00:00Z"
}
{
"shortUrl": "https://short.ly/abc123",
"shortCode": "abc123",
"expiry": "2026-06-01T00:00:00Z"
}
GET /{shortCode}
Example:
GET /abc123
shortCode
302 Found
Location: https://example.com/very/long/url
For user data, PostgreSQL is usually better because:
MongoDB can be considered if:
1. User submits long URL
2. URL Service generates short URL
3. Store mapping in PostgreSQL
4. Cache mapping in Redis with TTL
1. Client requests short URL
2. Check Redis first
3. If cache hit → return long URL
4. If cache miss:
→ query PostgreSQL
→ populate Redis
→ redirect user
Used as:
Used as:
High available -> Url and User service should be horizontal scalable and managed by eks so they are not
Low Latency -> reduce the call using redis, instead of db
Horizontal Scalability -> make the services horizontal scalable
Concurrent request ? how is that a issue, like multiple read can be supported using redis, and even if multiple reads on same row is it supported
Cache miss ? do we have to persist it somewhere else ?
Avoid Collisions -> avoid collision of url generation so in this we can have 7 bit uuid generation which will be unique