Express middleware chain vs external cache store: who owns invalidation?

Direct answer

The application layer owns invalidation. Express middleware must explicitly delete or replace cache entries when underlying data changes. The cache store only enforces TTL and eviction; it has no visibility into database writes, background jobs, or mutations from other services.

Confirmed behavior versus likely explanation

Confirmed: Express provides no native HTTP cache and no built-in hook that fires when external data changes. A cache store such as Redis or node-cache can expire a key by TTL, but it cannot know that a row was updated outside the request cycle. Likely explanation: after TTL expiry, Express continues serving the cached response until the next client request causes a miss, because the framework does not automatically revalidate on external mutation.

Middleware registration order

Register cache-read middleware early, before route definitions, so hits can short-circuit the handler. Register cache-write middleware after all routes, and attach the write logic to res.on('finish', ...) so the response body and headers exist before the socket flushes.

app.use(cacheReadMiddleware); // early
app.get('/resource', handler);
app.use(cacheWriteMiddleware); // after routes

Inside cacheWriteMiddleware, call next(), then use res.on('finish', () => cache.set(key, body, ttl)) to store the generated response. Do not place write middleware before routes; it may cache empty or undefined responses.

External mutation without race conditions

Have the worker, cron job, or other service publish an invalidation event, for example over Redis pub/sub. Each Express instance subscribes and calls cache.del(key) for the affected key. Use atomic store operations: SET key value NX EX ttl for writes and DEL for invalidation. For read-heavy workloads, accept a brief eventual-consistency window where one instance may serve stale data until it receives the invalidation message.

Steps for this case

1. Design cache keys that encode path, query parameters, authentication context, and relevant headers.
2. Add read middleware before routes to return cached hits and skip the handler.
3. Add write middleware after routes using res.on('finish') to store the generated response.
4. Wire external data mutations to publish invalidation events.
5. Subscribe in Express and delete the matching cache key on receipt.
6. Verify hit/miss behavior and invalidation propagation.

Missing diagnostic detail

Are you running one Express process or multiple instances behind a load balancer? This determines whether in-process invalidation is sufficient or whether you need distributed pub/sub and key versioning.

Verification

redis-cli CONFIG SET notify-keyspace-events KEA
node -e "const app = require('./app'); console.log(app._router.stack.map(l => l.handle.name));"

Hit an endpoint twice, confirm the second hit is served from cache. Mutate data externally, publish the invalidation event, then confirm the next request is a miss.

Assumptions and uncertainty

Assumes Express 4.x stable. Express 5 beta changes error-handling semantics, but res.on('finish') behavior remains stable; test upgrade paths separately. TTL semantics differ: in-memory stores often use sliding expiration, while Redis uses fixed TTL from SET. Mixing stores without normalization causes freshness mismatches. Pub/sub invalidation is eventually consistent, not strongly consistent.