The last chapter built the redirect with a deliberate 302 so every click flows back through our handler. Now we use that hook. This chapter adds click tracking, which means incrementing a per-URL counter on each successful GET /:code redirect. The interesting part is how we increment. A naive approach silently loses counts under concurrent traffic.
Atomic click increment on each redirect.
We add a new incrementClicks(shortCode) method to the UrlStore interface, implemented in both backends.
The redirect handler calls findByCode, then awaits incrementClicks before sending the 302.
The Prisma store performs the update as one atomic SQL statement so concurrent hits cannot lose a count.
What These Terms Mean
Before looking at the code, here are three concepts that drive this chapter.
Atomic increment: One SQL statement (UPDATE urls SET clicks = clicks + 1) where the database reads, adds, and writes as a single indivisible step. The data never leaves the database, leaving no window for a concurrent hit to slip through.
Read-modify-write: The naive alternative. This happens in three steps in application code: read the current clicks, add in JavaScript, and write the new value back. It works fine for one request at a time but causes race conditions under heavy traffic.
Tracking Clicks with Atomic Increments — Node.js TDD | dalabs.academy
1
Lost update: This is what goes wrong with read-modify-write under load. Two concurrent clicks both read 5, both compute 6, and both write 6. Two hits occurred, but the counter only moved by one. A click vanishes.
Why Do the Math in SQL
Doing the math in SQL is a specific design choice worth settling before we write a test. Imagine two redirects for the same code arrive at once, both starting from clicks = 5. With read-modify-write, both requests SELECT and see 5. Both add 1 in their own copy of the value, and both write 6 back to the database. The second write silently overwrites the first, and the counter lands on 6 instead of 7. Two hits happened, but only one was counted. This is a lost update. It is completely invisible. There is no error and no crash, just a number that is quietly too low.
The fix is to never pull the value into application memory at all:
UPDATE urls SET clicks = clicks +1WHERE short_code = $1;
sql
Postgres computes clicks = clicks + 1 under the row lock the UPDATE already takes. Two concurrent statements will serialize. One runs, then the other reads the newly updated value and adds to it. The counter lands on 7 no matter how many hits arrive at once. This is the reason we do the arithmetic in SQL rather than in JavaScript.
One thing we do not need is a database migration. The clicks column already exists. We added it back in chapter 11 as clicks Int @default(0), so a freshly shortened URL already starts at 0. This chapter touches nothing in the prisma/ folder. All we add is the code that updates an existing column.
Step 1: The Failing Test (Red)
We drive this with an integration test because the behavior we care about is a real number landing in a real urls row. The test persists a URL, hits GET /:code five times, then reads clicks straight from the database and asserts it equals five.
Check out the start branch and bring up the database:
git checkout 14-tracking-clicks-start
npm install
docker compose up -d --wait
bash
The new suite wires buildApp with PrismaUrlRepository so it exercises the full path through Postgres. The driver case persists a URL, hits GET /:code five times, then reads clicks straight from the database:
// __tests__/integration/click-tracking.test.ts
it("records N clicks after N successful redirects",async()=>{
Two sibling cases pass on the start branch already: "starts at zero" (the column defaults to 0) and "no increment on a 404" (an unknown code is never stored). The honest red test is the one above. The handler does not count hits yet, so after five GET requests, the row's clicks value stays at its default. We assert against the database directly with prisma.url.findUnique because that row is the source of truth the stats endpoint will read in chapter 16.
Run the integration suite:
npm run test:integration
bash
Click count stays 0 — the tracking test fails.
This is an honest behavioral failure. The redirect returns its 302 five times, but nothing increments the counter, so the row reads 0 instead of 5. With the container up, this is a real behavior gap, not a connectivity or compile error.
Step 2: Add incrementClicks to the Seam (Green)
Switch to the finish branch:
git checkout 14-tracking-clicks-finish
npm install
bash
The new behavior goes behind the same UrlStore interface the redirect already depends on. We add one method, incrementClicks, and implement it in both backends. The handler then calls it without ever learning which store it is talking to.
The in-memory store keeps a second Map for the counts. The save method seeds a new code at 0 so it mirrors the database default. incrementClicks is a no-op for a code that was never saved, which matches the "no row to update" behavior in the database.
Notice getClicks. This is test-only scaffolding. It allows the Docker-free unit tests to assert the counter without a database. It is deliberately missing from the UrlStore interface because the route never needs to read a count.
The Prisma store does the increment the way that matters: atomically.
{ clicks: { increment: 1 } } is Prisma's atomic-increment shorthand. It compiles to UPDATE urls SET clicks = clicks + 1 WHERE short_code = $1. This is one statement where the database does the arithmetic. This is the read-modify-write fix from earlier, now in real code. There is no SELECT, no value held in JavaScript, and no lost-update window.
Step 3: Count the Hit in the Handler
With the interface updated, the redirect handler counts the hit after a successful lookup and before sending the 302. The 404 branch is untouched. An unknown code is never counted.
The handler stays thin. It has no direct database access and talks only to the UrlStore interface. The exact same code runs against the in-memory store for unit tests and Prisma for integration and production. This is the chapter-6 seam paying off once more. A new storage capability slots in behind the interface without the route changing shape.
Awaited vs Fire-and-Forget
There is one real decision left. Do we await the increment, or fire it off and return the redirect immediately? We chose to await. The trade-off is worth understanding because the other choice is defensible in a different context.
Awaited (chosen)
Fire-and-forget
Latency
Adds one round trip before the 302
Returns the redirect immediately
Correctness
Increment is guaranteed before the response returns
Increment may not have run yet when the response leaves
Failure visibility
A failed UPDATE surfaces (the handler awaits a rejected promise)
Becomes a silent unhandled rejection; the count is lost on a crash
Complexity
None — just await
Needs a deliberate .catch() so a rejection can't take the process down
Why awaited here: At this stage, correctness and simplicity beat shaving a few milliseconds off a redirect. Awaiting keeps the count exact and lets a failed increment surface instead of vanishing.
Fire-and-forget means returning the 302 first and running the increment in the background. This is the right call when redirect latency dominates and an occasional lost count is acceptable. However, it needs an explicit .catch() so an unhandled rejection cannot crash the process, and it trades a guarantee for speed. We note the trade-off and pick the guarantee.
A Note on Concurrency
The atomic increment we just wrote makes concurrent click counting correct. If ten redirects for the same code arrive at once, they all run SET clicks = clicks + 1. The statements serialize on the row lock, and the counter moves by exactly ten. There is no application-level lock and no retry loop. The database handles it. We flag concurrency here so it is fresh in your mind, but this particular race condition is solved.
A different operation is still racy, and it is the one chapter 19 tackles: short-code generation. Two concurrent POST /shorten requests can independently generate the same code. Both check if it is free, and both see that it is. Then one INSERT wins while the other hits the urls_short_code_key unique constraint.
The @unique index makes a duplicate impossible to persist. Turning that constraint violation into graceful behavior, like retrying with a fresh code or serializing generation with a PostgreSQL advisory lock, is the topic of chapter 19. Atomic increment solves concurrency for counting. Advisory locks solve it for unique-code generation.
Step 4: Green on Both Suites
The finish branch also adds three Docker-free unit cases. These exercise the in-memory store's counter directly (start at zero, N increments yield N, ignore an unknown code). This proves the increment logic works quickly without a container. Run everything:
npm test
npm run test:integration
bash
Unit and integration tests passing.
Both suites are green. The unit suite proves the increment logic in milliseconds. The integration test proves five real redirects land clicks = 5 in an actual Postgres row.
When you're done, stop the container:
docker compose down -v
bash
What's Next
The database is accumulating real usage data, but there is no way to see what is stored. Next, we list all URLs with a paginated GET /urls endpoint using schema-validated paging parameters.
