The stale redirect

Why it matters

Words you need

Cache

A fast copy of data kept close by, here in Redis, so most reads skip the database.

Cache-aside

Read from the cache; on a miss, read the database and put the result in the cache. The most common way to cache.

Invalidation

Removing or replacing a cached copy after the real data changed, so nobody reads the old one.

TTL (time to live)

How long a cached copy lives before it expires on its own. It caps how long a wrong copy can survive.

Race condition

A bug that only appears when two requests overlap in an unlucky order. Each request is correct on its own.

Lease

A marker a request leaves in the cache on a miss. Its later fill only counts if the marker is still there.

Picture it

sho.rt/g8 points to old-site.com, and its cached copy has just expired. A visitor opens it while the owner changes it to new-site.com.

Break it yourself

The fixes people try

• Delete first, then update

  Fails
  redis.del(); db.update()

  A visitor can miss right after the delete, read the old value, and write it back. The gap moves; it does not close.

• Delete twice

  Fails
  del; update; sleep(500); del

  Shrinks the gap. A visitor slower than the sleep still writes the old value after the second delete.

• Write the new value into the cache

  Fails
  db.update(); redis.set(new)

  Two writers, and the last one wins. The slow visitor's old value can land after the owner's new one.

• A short TTL

  Half a fix
  redis.set(key, target, "EX", 60)

  Caps how long a wrong copy lives, but every link expires sooner, so Postgres serves more misses. A good backstop, not a fix.

• Lock the row for misses and edits

  Works
  SELECT target … FOR UPDATE

  Correct, but every cache miss holds a database lock while it talks to Redis, on your busiest path.

• Fill with a lease

  Works
  SET key fill:<id> NX, fill only if still ours

  An edit's delete removes the marker, so a fill that started before the edit is refused. No locks on the redirect path.

The fix and its cost

Check yourself

1. 1Update the database, then delete the cache. How can the cache still end up wrong?Show answerHide

   A visitor that missed the cache reads the old target before the update, then writes it into the cache after the delete.

2. 2Why doesn't deleting twice fix it?Show answerHide

   It shrinks the gap, but a visitor slower than the wait still writes the old value after the second delete.

3. 3How does a lease stop the stale fill?Show answerHide

   The edit's delete also removes the visitor's marker, and the fill only writes while its marker is there. A value read before the edit can't be written after it.

The code

import type { Pool } from "pg";
import type Redis from "ioredis";

const TTL = 86_400; // one day

// Redirect: serve from Redis, fill it from Postgres on a miss.
export async function resolve(db: Pool, redis: Redis, code: string) {
  const key = `link:${code}`;
  const hit = await redis.get(key);
  if (hit) return hit;

  const { rows } = await db.query(
    "SELECT target FROM links WHERE code = $1", [code],
  );
  const target: string | undefined = rows[0]?.target;
  // If an edit landed after the SELECT, this writes the old target back.
  if (target) await redis.set(key, target, "EX", TTL);
  return target;
}

// Edit: update Postgres, then drop the cached copy.
export async function updateTarget(
  db: Pool, redis: Redis, code: string, target: string,
) {
  await db.query(
    "UPDATE links SET target = $2 WHERE code = $1", [code, target],
  );
  await redis.del(`link:${code}`);
}