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

Integration boundary

Express provides routing and middleware but no native HTTP caching. Applications must integrate an external cache store such as Redis or node‑cache, creating a split responsibility: Express controls request flow while the cache store controls TTL and eviction.

Unresolved behavior

When a cached entry expires, Express continues serving the stale response until the next client request triggers a cache miss. The framework does not prescribe whether cache‑writing middleware should run before or after route handlers, and it offers no built‑in hook to invalidate cache entries when underlying data changes externally (e.g., a database update).

Goal and constraints

The goal is a predictable freshness guarantee across the Express–cache boundary without custom framework patches. Constraints include the lack of documented middleware ordering, divergent TTL semantics between in‑memory and distributed stores, and the requirement that invalidation logic be implemented manually.

Which component should own the invalidation decision—Express middleware or the cache store? What middleware registration order ensures cache‑write runs after the response is generated but before the response is sent? How can an external data mutation reliably purge or update the corresponding cache entry without race conditions?