Cache invalidation
Find which cache is still serving the old value
Trace one response through browser, edge and application layers before clearing everything. A broad purge can hide the cause and overload the source.
In this article
Establish the authoritative value
Choose a specific affected resource and confirm its current state through an appropriate source read. Record the revision and update time. If the source is itself a replica or projection, identify the authoritative write location before blaming caching.
Capture the user-visible response and relevant response headers. Note the account, language and other inputs that could legitimately change the representation.
A different result is not always a stale result. An incorrect tenant or price-list key can produce fresh data belonging to the wrong context.
Bypass layers one at a time
Compare the ordinary browser request with a controlled origin request and, where available, a diagnostic application read. Use approved diagnostic controls rather than exposing a public bypass that arbitrary callers can abuse.
Look at response age, validators and cache status signals provided by the infrastructure. Treat them as evidence for the layer that produced them, not proof about every downstream cache.
If the origin is correct but the browser remains old, inspect client-side query state, service worker behaviour and HTTP policy. Clearing the server cache will not necessarily change an application-held value.
Repair the narrow cause
For a known stale entry, invalidate the correct scope and confirm that refill loads the expected revision. Watch for a paused or delayed reader repopulating an older value.
If the key omits a context dimension, fix the key and move to a new namespace where appropriate. Purging the old entry alone only changes which caller populates the next incorrect result.
Avoid a full purge unless its impact is understood. An empty cache can send a sudden concentration of reads to the database. Use controlled refill and source protection when the affected scope is large.
Verify the user's path
Repeat the original request under the same account and presentation settings. Confirm both the displayed result and any business operation that depends on it.
Record which layer was wrong, why its expiry or invalidation did not resolve the issue and how the fix prevents recurrence. Include a regression case for the exact resource scope or interleaving involved.
If stale data was allowed during an outage, check that normal freshness resumed after recovery. A temporary fallback should not silently become the application's permanent behaviour.
Primary sources
HTTP caching standardReferences checked 11 September 2026.