Negative Caching
On this page · 2 min read
Revised October 19, 2026. What changed
Negative caching stores an absence or failure so the next request need not repeat the same work. It can be useful. The failure mode is treating every negative response as equally stable.
Separate absence from an outage
A missing product in a slowly changing catalogue may be worth caching briefly. A database timeout says nothing about whether the product exists. Reusing that timeout as “not found” converts a temporary dependency failure into a false statement about the data.
HTTP caching explicitly permits negative responses under its storage rules. Whether a particular response may be stored and reused depends on status, cache directives, authorization, and the cache context. “Negative response” alone is not a prohibition.
Write the policy before the annotation
| Outcome | Example policy | Invalidation |
|---|---|---|
| Confirmed absence | Short, explicit TTL if bounded staleness is acceptable | Evict on creation; otherwise expire |
| Timeout or dependency unavailable | Do not store as absence; use a distinct error and bounded retry/backoff | Retry under a separate failure policy |
| Authorization failure | Do not share across identities or scopes | Account for policy changes and credential scope |
These are design examples, not universal TTL settings. Pick a lifetime from the cost of stale absence and the dependency load you can tolerate. A framework cache annotation does not establish the right domain policy; inspect its key, exception, null, and invalidation behavior.
Test recovery, not only cache hits
Request a missing key, create it, then repeat the lookup. Verify that your invalidation or expiry makes it visible within the promised window. Separately inject a timeout and prove the next successful lookup is not suppressed. Returning a domain object instead of an HTTP wrapper is not enough if the cache still conflates these outcomes.