# A high cache hit rate can hide stale answers

Measure freshness and user-visible correctness alongside speed. A cache that repeatedly serves the wrong value can look excellent on a performance dashboard.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Define a stale result precisely

A value is not necessarily defective just because a newer revision exists. Some screens deliberately allow a short delay. Measure against the freshness promise for the operation rather than treating every mismatch identically.

For a stock preview, the promise might allow a bounded delay while checkout uses authoritative availability. For an access decision, that same delay may be unacceptable. Keep these classes separate in reporting.

Record the source revision or load time where feasible. Without provenance, investigations often cannot tell whether a cache served old data or the source itself was already behind.

## Sample against an independent read

For a small, controlled fraction of suitable requests, compare the cached result with the authoritative source. Avoid doubling all backend traffic simply to monitor a cache designed to reduce it.

Interpret differences carefully when writes occur between the two reads. A comparison needs timestamps or revisions to distinguish expected concurrency from a breached freshness window.

Track the mismatch rate by resource class and operation. Avoid putting individual customer identifiers into high-cardinality metric labels. Keep record-level evidence in access-controlled diagnostics.

## Measure update visibility

In a synthetic check, write a known value and observe when the normal read path returns it. This measures the combined effect of application, edge and browser policy more directly than cache deletion success alone.

Report the distribution and the worst observed cases within a defined period. An average can hide a small group of records that remain stale until a long expiry.

Also monitor invalidation failures, refresh errors and source load during cache misses. A low stale rate achieved by overwhelming the database is not a sustainable result.

## Set acceptance around the task

Use separate criteria for latency, freshness and safe failure. An illustrative release might require the product page to meet its agreed response budget, updates to become visible within the defined window and checkout to reject unavailable stock regardless of the display cache.

Do not copy those conditions to unrelated data. The business consequence determines the threshold and whether stale fallback is permitted.

Review results during a cold start and a source outage as well as steady traffic. The cache is acceptable when it supports the task across those conditions, not merely when most requests happen to find an entry.

## Sources

- [Microsoft: cache-aside pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cache-aside)