Negative Caching and Cache Consistency

Negative caching can turn a temporary absence into a persistent error.

A resource can be successfully created in PostgreSQL and still return 404 for several minutes, not because the database lost the write, but because an earlier cache miss was stored as if the absence were durable.

When a Miss Becomes Stale

Consider 𝘎𝘌𝘛 /𝘪𝘵𝘦𝘮𝘴/42 arriving before the item exists: the API queries its source of truth, returns 404, and stores a 𝘕𝘖𝘛_𝘍𝘖𝘜𝘕𝘋 marker in Redis to avoid repeatedly hitting the database for nonexistent IDs.

A moment later, 𝘗𝘖𝘚𝘛 /𝘪𝘵𝘦𝘮𝘴 creates that resource and commits the transaction, but the subsequent read never reaches PostgreSQL because the cached negative result continues to answer the request until it expires.

This is the subtle difference between caching a value and caching an observation: "not found" does not mean "will not exist", and its validity can change immediately after a successful write elsewhere in the system.

Choosing What to Cache

A negative cache can still be useful for protecting a database from repeated lookups of invalid identifiers, especially when the underlying data is expensive to resolve and absence is unlikely to change.

But confirmed absence, pending materialization, and operational failures are not interchangeable: timeouts or temporary connection errors should not silently become 𝘕𝘖𝘛_𝘍𝘖𝘜𝘕𝘋, because that converts an outage into an incorrect answer.

Managing Negative Entries

For mutable resources, define negative TTLs according to how long a false 404 is acceptable, invalidate the relevant key on creation when possible, and include tenant and authorization scope in keys to avoid leaking decisions across callers.

The architecture question is not simply whether a lookup deserves a cache entry. It is whether that entry represents a stable fact, a temporary observation, or an error that should never be cached as absence.