Add `GET /shorten/available/:slug` (check a custom slug before submitting it)

Nobody has started this yet — be first.

Business impact

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.

Problem

GET /shorten/available/:slug is registered as a stub in src/routes/shorten.js (right before module.exports). It compiles and the route exists, but its handler unconditionally throws -- hitting it always returns a 500 with a generic "Internal server error" body, regardless of :slug.

Current behavior

GET /shorten/available/any-slug always returns HTTP 500, never a real available: true/false answer.

Expected behavior

GET /shorten/available/:slug validates the path parameter using the same slug format rules POST /shorten already enforces for customSlug (3–32 chars, [a-zA-Z0-9_-]+). A malformed slug returns 400 with a validation error body in the same shape the existing errorHandler already produces for ZodErrors. For a well-formed slug, it returns 200 { "available": true } if no Link currently has that shortCode, or 200 { "available": false } if one does. It is strictly read-only -- it never creates, modifies, or reserves anything, and makes no promise the slug will still be free by the time a real POST /shorten for it lands (that race is what the existing 409 collision handling on POST /shorten is already for).

Steps to reproduce

npm run dev curl -s http://localhost:3003/shorten/available/brand-new-slug

-> 500 Internal Server Error

Why this matters

There's no new concept here -- this is a read path that reuses two things that already exist in this codebase: the customSlug Zod schema (for format validation) and findByShortCode (for the existence check, src/lib/linkService.js). The main thing to get right is reusing them rather than re-deriving your own regex or your own Prisma query -- if your slug-format rules drift even slightly from what POST /shorten actually enforces, this endpoint could tell a client "available" for a slug that POST /shorten would then reject as malformed, or vice versa.

Suggested approach

Look at customSlug in src/lib/validation.js -- it's already exported indirectly as part of shortenRequestSchema, but you can also parse a bare string against a Zod schema on its own (someSchema.parse(value), throwing a ZodError on failure -- which the existing errorHandler already knows how to turn into a 400, the same way every other route in this file handles validation). For the existence check, findByShortCode in src/lib/linkService.js already does exactly the lookup you need -- you just have to decide what "found" vs. "not found" means for available.

Acceptance criteria

GET /shorten/available/:slug for a slug that isn't taken returns 200 { "available": true }.
GET /shorten/available/:slug for a slug that is taken (an existing Link.shortCode) returns 200 { "available": false }.
GET /shorten/available/:slug for a malformed slug (e.g. "ab", too short) returns 400, not 500 and not a false available verdict.
The endpoint never writes to Postgres or Redis.

Verification

npx jest --config practice-tickets/jest.config.js practice-tickets/tests/02-slug-availability-check.test.js

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b feat/slug-availability-check

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin feat/slug-availability-check

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

URL Shortener — Redirect Latency vs. Click-Count Correctness

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.

Fork on GitHub

Download

Setup

URL Shortener — Redirect Latency vs. Click-Count Correctness

git clone <your-fork>
cd url_shortener
cp .env.example .env
npm install                       # also runs `prisma generate` via postinstall
docker compose up -d postgres redis   # or point .env at Postgres/Redis you already run
npm run prisma:migrate:dev        # applies prisma/migrations, creates the db schema
npm run dev                       # nodemon, http://localhost:3003