Cache invalidation
Review the read that follows a successful write
Users expect to see the change they just saved. Check the whole response path before accepting a cache policy that can return the previous value immediately afterwards.
In this article
Follow one edit through the interface
Use a concrete action such as changing a project name. The save request succeeds, the interface returns to the project list and the old name appears. The database may be correct while a list cache or client query still holds the earlier representation.
Map every read triggered after the write. Include detail views, lists, counts and search results. Updating the detail cache alone may leave all other representations unchanged.
Decide which views must reflect the user's own write immediately and which can update later. This is an interaction requirement, not merely a backend consistency label.
Inspect the success response
Returning the committed representation can let the interface show the confirmed value without immediately fetching an older copy. Ensure it really represents committed state rather than echoing the submitted request before validation or normalisation.
If the interface uses optimistic updates, test server rejection and server-adjusted values. The local display must reconcile with the actual result.
Keep pending and confirmed states distinct where the write completes asynchronously. A queued request should not be presented as a completed business change just to make the screen feel responsive.
Review invalidation dependencies
Identify keys and client queries affected by the mutation. A project rename can alter a detail record, filtered list and search document. The appropriate recovery may differ for each.
Check failed invalidation and concurrent refill. A successful database commit does not make every cache update atomic with it. If immediate confirmation matters, use a read path that can establish the committed revision.
Avoid broad invalidation as the default response to an unclear dependency graph. It can make the interface slower and create unnecessary source load while still missing another layer.
Test under realistic navigation
Save from one tab and read from another. Navigate back, switch filters and revisit the page without a full reload. Include a slow network response arriving after the successful save, since it can overwrite a newer client value.
Verify behaviour after a process restart and a rolling deployment. Local memory can hide cross-instance differences during development.
Approve the policy when the observed sequence matches the intended experience. The review evidence should show the committed revision and what the user sees at each step, rather than only a successful mutation status.
Primary sources
Microsoft: cache-aside patternReferences checked 11 September 2026.