Loading challenges
A production-quality Express/Prisma/Redis URL shortener whose central engineering problem is keeping the redirect path fast while still counting every click correctly -- async, fire-and-forget click logging that never adds latency, backed by a single atomic SQL increment instead of a read-then-write.
Nobody has started this yet — be first.
`/health` reports "ok" when only one dependency is actually up
GET /health exists for exactly one reason: to let a Docker healthcheck, a Kubernetes readiness probe, or a load balancer decide whether to keep sending this instance traffic. Right now, if Postgres goes down but Redis is still reachable (or vice versa), /health reports 200 { status: "ok" } anyway. The orchestrator sees a healthy instance and keeps routing real user traffic to it -- every POST /shorten and every cache-miss GET /:code behind that "healthy" instance then fails with a 500. On-call ends up chasing a spike in 500s against a fleet that every dashboard says is green, because the one signal that's supposed to catch this is lying. It also directly contradicts this project's own README, which explicitly promises "Returns 200 only if both checks pass, 503 otherwise."
About this project
A base62 URL shortener: short codes are the base62 encoding of the Link row's auto-incrementing Postgres id (hand-rolled encode/decode, no library), so codes are collision-free by construction and denser than hex with no uniqueness-retry loop needed. A Redis cache-aside layer sits in front of the redirect path -- a cache hit skips Postgres entirely, a miss populates Redis with a TTL clamped to the link's own expiry -- and creation is write-through, so the very next lookup after a link is created is already a cache hit.
The interesting engineering problem sits squarely in the redirect handler: the client must be redirected immediately, but the click still has to be counted -- correctly -- after the HTTP response has already gone out the door. resolves the destination, issues , and only then schedules the click increment via , unawaited; the increment itself must be a single atomic , never a sequence in application code, because Node's event loop can freely interleave concurrent calls between a read and its matching write. Around that core tradeoff sit a handful of correctness-critical details that are easy to get subtly wrong: a that must report unhealthy the instant dependency is down (not just when are), a cache TTL calculation that has to round up rather than down for sub-second-remaining links, and two independently-configured rate limiters (strict for the expensive write endpoint, loose for the cheap redirect) that are only correct if each is wired to the right route.
Add `GET /shorten/available/:slug` (check a custom slug before submitting it)
Today the only way to find out whether a customSlug like "launch-2026" is already taken is to submit the full POST /shorten request and see if it comes back 409. For a client building a "claim your custom link" UI with live feedback as the user types, that means firing a real write attempt just to answer a yes/no question, and it means every "just checking" keystroke burns a slot out of the strict POST /shorten rate limit (10/min) -- a user experimenting with a few slug ideas could lock themselves out of actually creating their link. A cheap, read-only availability check fixes both problems.
GET /:coderes.redirect(302, ...)setImmediateUPDATE ... SET clicks = clicks + 1read clicks, compute +1, write clicksGET /healthSeven tickets are deliberately injected into an otherwise working, fully-tested codebase -- four bugs (an inverted health-check boolean, a TTL rounding bug that silently defeats the cache for soon-to-expire links, two rate limiters wired to each other's routes, and the read-then-write lost-update race in click counting) and three enhancements scaffolded with a throwing stub rather than a real implementation (a slug-availability check, a most-clicked leaderboard, and link deletion with cache eviction). Every ticket has a dedicated Jest test, run against real Postgres and Redis, that goes green when the fix is correct -- and fixing several of them (01, 03, 04, 07) also turns pre-existing failures in the project's own real test suite back to green, since the injected bugs live in code that suite already exercises.