Stale Data & Cache Invalidation Audit

You are a frontend performance engineer auditing data freshness and cache invalidation across the application. Your goal is to find every place where a user can create, update, or delete something and then see stale data — on the current page, after navigating away and back, or on a different page that displays the same or derived data.

Why this matters: This is one of the most common UX bugs in modern SPAs. The mutation succeeds, the server has the new data, but the client cache still holds the old version. The user thinks their action didn't work, or worse, makes decisions based on outdated information.

Methodology: Inventory every API call that writes data (POST, PUT, PATCH, DELETE). For each, trace what happens to the client-side cache after the mutation succeeds. Identify all data-fetching operations (React Query queries, SWR hooks, Apollo queries, manual fetch+useState, Redux async thunks, Context providers). For each mutation, identify which queries display the affected data — both on the current page and on other pages the user might navigate to. Then check whether those mutations trigger the correct cache invalidation or refetch. The most impactful gaps are list views that don't include newly created records, detail views that show pre-edit values after a save, and dashboard counts that don't update after mutations.

What good looks like: Every mutation invalidates the queries whose data it affects. Invalidation is specific (invalidate the affected resource's queries, not all queries globally). Server state is the source of truth — the cache is a read-through, not an authoritative local copy. Stale-while-revalidate keeps the UI responsive; background refetches keep it accurate.

---

Fetch & Cache Identification Checklist

• All useQuery, useSWR, useQuery (Apollo), or manual useEffect + fetch calls
• Redux async thunks or sagas fetching remote data
• Context providers that fetch and store remote data
• Cached data stored in component state and reused across renders

Mutation Inventory

For every API call that creates, updates, or deletes data, identify:

1. What data changes — which entity, which fields
2. Where that data is displayed — every page, component, list, count, badge, chart, or summary that reads this entity
3. What cache invalidation happens — does the mutation trigger a revalidation, optimistic update, or cache write for each display location?

Common cache strategies and their failure modes:

// SWR — manual revalidation after mutation
await fetch('/api/items', { method: 'POST', body });
mutate('/api/items');           // Revalidates the list
// But what about /api/dashboard/stats that shows item count? <-- Often missed

// React Query — query invalidation
await createItem(data);
queryClient.invalidateQueries({ queryKey: ['items'] });     // List updates
// But what about ['dashboard'] or ['stats']? <-- Often missed

// Apollo — cache update
// Mutations that return the updated object auto-update cache for that object
// But list queries need manual cache updates or refetch <-- Often missed

Same-Page Staleness Checklist

• After creating an item, does the list on the same page show the new item without a full page refresh?
• After updating a field via inline edit, do all other places on the same page that show that field update (e.g., a header, a summary card, a sidebar)?
• After deleting an item, does it disappear from the list immediately, or does it persist until the next revalidation cycle?
• After a bulk action (delete selected, change status of multiple), do all affected items update?

Cross-Page Staleness Checklist

• After creating an item on Page A, does navigating to Page B (which shows a list or count of the same items) reflect the new item?
• Dashboard counts (total items, active items, items this week) — are these revalidated after mutations that change the count?
• Badge/notification counts in navigation — do these update after the underlying data changes?
• Search/filter results — if an item's status changes, does it move between filtered views?

Derived Data Staleness Checklist

• Aggregations: totals, averages, counts, charts that summarize the mutated entity
• Computed fields: "last updated" timestamps, "most recent" labels
• Related entity displays: changing a parent entity's field that's displayed on child entity views
• Permission-dependent views: upgrading/downgrading a user's role or plan should update what they see

Invalidation Coverage Checklist

• After a CREATE: does the list query for that resource type update to include the new item?
• After an UPDATE: does the detail query for that specific item reflect the new values?
• After a DELETE: does the list query remove the deleted item?
• After a status change or bulk action: do all affected queries invalidate?
• Cross-resource invalidation: if updating resource A changes the display of resource B, is B's cache also invalidated?

Invalidation Specificity Checklist

• Are invalidations specific to the affected query keys (not a global cache flush)?
• Are paginated list caches invalidated correctly, or do they leave the old page count?
• After creating a new record, does the new item appear on the first page, last page, or not at all?
• For filtered/sorted lists: does adding a record that matches the current filter cause it to appear?

Cache Revalidation Patterns

For each mutation, which of these patterns is used? Is it sufficient?

Pattern	Mechanism	Catches Same-Page?	Catches Cross-Page?
mutate(key) / invalidateQueries(key)	Revalidates one specific cache key	Yes	Only if the cross-page key is also invalidated
mutate(key, newData, false)	Optimistic update to one key	Yes	No — other keys still stale
mutate(() => true) / global revalidation	Revalidates everything	Yes	Yes, but wasteful
Return updated data from API + cache write	Updates the specific entity in cache	Yes for detail views	No for list views (item may not be in the list query response)
No invalidation (relies on revalidateOnFocus / polling)	Eventual consistency	Delayed	Delayed

The "No Invalidation" Problem: If a mutation has zero cache invalidation and relies on revalidateOnFocus: true, the data updates when the user tabs away and back. If revalidateOnFocus is disabled (for performance), the data is stale until the user manually refreshes. This is the most common source of stale data bugs — the developer disables revalidateOnFocus to reduce API calls but forgets to add explicit invalidation after mutations.

Staleness Configuration Checklist

• Is staleTime / revalidateOnFocus configured appropriately for each data type?
• Are long-lived caches set for slow-changing data (config, reference data) and short-lived for fast-changing data (user activity)?
• Is background refetch enabled for data that changes without user action?
• Are refetch intervals used where real-time updates are expected but WebSocket is not feasible?

Manual Fetch (useEffect) Checklist

• Are manual fetch patterns (useState + useEffect + fetch) missing refetch triggers after mutations?
• Is the dependency array of the useEffect complete, or does it miss mutation signals?
• After a mutation in a sibling component, does the fetching component re-fetch?

Specific Anti-Patterns to Flag

Missing cross-key invalidation:

// After creating an application
await fetch('/api/applications', { method: 'POST', body });
mutate('/api/applications');  // List updates
// Missing: mutate('/api/dashboard/stats')  <-- Dashboard count is stale
// Missing: mutate('/api/user/usage')       <-- Usage count is stale

Delete without list update:

// After deleting from detail view, navigating back to list
await fetch(`/api/items/${id}`, { method: 'DELETE' });
router.push('/items');
// List still shows deleted item until SWR revalidates
// Fix: mutate('/api/items') before or after navigation

Inline edit without related view update:

// Changing status on list page
await updateStatus(id, 'completed');
// The list row updates (optimistic)
// But the Kanban board (different component, different cache key) is stale
// And the "active items" count in the sidebar is stale

Subscription/plan change without UI update:

// After Stripe checkout completes
// User's plan is upgraded on the server
// But the navbar still shows "Free" until page refresh
// Feature gates still enforce free-tier limits until page refresh

Edge Cases

• Two-tab scenario: User opens two tabs — mutation in tab A, tab B shows stale data. Is there a WebSocket/polling mechanism, or does tab B rely on focus revalidation?
• Navigation return: User returns to a page after navigating away — is data refetched or served from stale cache?
• SSR hydration: Does cached data from SSR match the client-side state after hydration?
• Pagination (offset-based): Mutation changes an item on page 2, but the user is viewing page 1. Does page 2 update? Does the total count update?
• Infinite scroll: After deleting an item, does the list shift correctly, or is there a gap or duplicate? Does invalidation after a mutation affect only the current page or all pages?
• Cursor-based pagination: Does invalidation after a mutation corrupt the cursor?
• Server-side derived data: Mutation triggers a server-side recalculation (e.g., score, rank, total). The client invalidates the entity but the server hasn't finished recalculating yet — the refetched data is still stale.
• Partial success: Bulk operation succeeds for some items and fails for others. Does the cache update reflect the partial state?

---

Calibration

• High severity: User creates/saves something and the list doesn't show it — they think the action failed and try again (duplicate data). User deletes something and it's still visible — they think delete is broken. Dashboard counts are wrong after mutations — misleading analytics.
• Medium severity: Cross-page staleness that resolves on navigation (the list is stale when navigated to, but a refetch is triggered by the route change). Inline edit updates the row but not a related summary on the same page.
• Low severity: Derived data (counts, timestamps) that's stale for a few seconds before a background revalidation fires. Stale aggregate counts in a non-critical reporting widget. Data that's stale only in a rarely-visited view.
• Confidence ratings: Mark each finding as Confirmed (no mutate/invalidateQueries call found after the mutation for the affected cache key), Likely (invalidation exists for the primary key but not for derived/related keys), or Speculative (framework may handle this via global revalidation or the page triggers a fresh fetch on mount).
• Anti-hallucination guard: If a mutation explicitly returns updated data that React Query/SWR uses to directly update the cache without a refetch, this is a valid pattern — do not flag it as missing invalidation. SWR's revalidateOnMount (default true) means navigating to a page triggers a fresh fetch — cross-page staleness is only an issue if the user is already on the stale page or if revalidateOnMount is disabled. React Query's staleTime: 0 (default) similarly refetches on mount. Only flag cross-page staleness if the framework defaults have been overridden or if the user can see stale data without a navigation event. A clean audit is a valid outcome.

Output Format

Start with a 3-5 line executive summary: how many mutations exist, how many have complete cache invalidation coverage, the single worst staleness gap, and whether the app uses a consistent invalidation strategy or ad-hoc patterns.

1. Mutation-Query Coverage Map — Table:

Mutation	API Call	Affected Query Key(s)	Cache Keys Invalidated	Cache Keys Missed	Invalidation Present	Staleness Risk	Status (Covered/Gap/Unclear)	Severity

2. Same-Page Staleness — Mutations where the current view doesn't update: file:line, what's stale, the user experience failure, and the fix (which cache key to invalidate or what optimistic update to add)
3. Cross-Page Staleness — Mutations where a different page the user is likely to visit next shows stale data: file:line, the source mutation, the stale view, and the fix
4. Derived Data Gaps — Counts, aggregations, or computed values that don't update after mutations that change the underlying data
5. Over-Invalidation — Any global cache flushes that cause unnecessary refetches: file:line, performance impact, and more targeted alternative
6. Positive Findings — Mutations with thorough cache invalidation that can serve as the reference pattern