Building LinkCut: A Sub-20ms URL Shortener with Next.js, FastAPI, and Redis

Gaurav Sethi — Mon, 24 Aug 2026 19:29:42 +0000

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 INCR for 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.