Hi, i'm Gaurav. This is my first post to dev.to
What is LinkCut?
LinkCut is a free, open-source URL shortener with no signup required — paste a link, cut it, share it. No accounts, no tracking cookies, no dashboard bloat.
- 🔗 Live app: https://linkcut-nine.vercel.app/
- 💻 Repo: https://github.com/Gaurav5189/url-shortener
Why I built it
I wanted to design a system where redirect latency actually mattered, not just a CRUD app with a UI wrapper. That meant thinking about caching, write-amplification, and decoupling reads from writes — not just "shorten a string and save it to a DB."
Architecture
The core idea: separate the fast path from the slow path.
-
Fast path (Edge Middleware): checks Redis first, returns a 302 redirect directly from the edge, and fires a non-blocking
INCRfor click tracking. - Slow path (Backend fallback): on a cache miss, FastAPI decodes the Base62 short code to an integer ID for an O(1) indexed lookup in SQLite, then repopulates Redis with a 12-hour TTL.
- Background path (Cron): flushes Redis click counters into SQLite periodically using an atomic Lua script — read-and-delete in a single Redis transaction, so counts never get double-counted or lost.
This keeps redirects fast (sub-20ms) while analytics writes stay off the hot path entirely.
Tech stack
- Frontend/Edge: Next.js (App Router) on Vercel Edge Middleware
- Cache/Counter: Redis
- Backend: FastAPI
- Database: SQLite
- Encoding: Base62, 5-character codes from auto-incrementing IDs (~916M capacity)
What I learned
I underestimated this going in. The URL shortening part is trivial — the interesting engineering is in the caching strategy, avoiding database write-amplification on every click, and making sure the analytics counter flush is atomic so nothing gets lost or double-counted under concurrent traffic.
Feedback on the caching strategy or architecture decisions welcome — always looking to improve it.
