Case Study
Designed and implemented a scalable URL shortening service with analytics tracking, rate limiting, and collision-resistant hash generation. Built with clean architecture principles for maintainability.
Overview
A URL shortening service built from first principles — not as a tutorial project, but as an exercise in designing a system that handles real throughput requirements cleanly. The goal was sub-100ms response times under load, with reliable analytics and collision-resistant short codes.
The constraint
Hash collisions are a deceptively tricky problem at scale. The system also needed to handle traffic spikes without hammering the database on every redirect — which required a thoughtful caching strategy rather than just adding Redis as an afterthought.
Highlights
Implemented a hash generation strategy that produces short, URL-safe codes while guaranteeing uniqueness across high write volumes. The algorithm handles collision detection gracefully without requiring database locks or sacrificing throughput.
Hot URLs are cached in Redis on first access, meaning the database is only hit on cache misses. This keeps redirect latency under 100ms even under heavy load and dramatically reduces read pressure on PostgreSQL.
Per-user rate limiting prevents abuse, and every redirect is logged with timestamp, referrer, and user-agent data — giving a real analytics layer on top of what is otherwise a stateless operation.
Stack
Node.js · TypeScript · PostgreSQL · Redis · Docker · Next.js · Jest
Building this service from scratch clarified how much architecture work hides inside products that look trivially simple. Short URLs are a solved problem — until you care about performance, reliability, and observability.