Mutations and Cache Invalidation in Practice

The plain-language idea

Once data is cached client-side, a mutation (a POST/PATCH/DELETE that changes something on the server) leaves the cache holding a value that's now wrong. Something has to reconcile the two, and there are exactly two concrete ways to actually write that code:

• Invalidate-and-refetch — after the mutation succeeds, mark the affected cache key(s) as stale and let a real network request fetch the current value again. Simple to write and always correct, because the new value comes straight from the server, but it means a second round-trip has to complete before the UI reflects the change.
• Direct cache write — after the mutation succeeds, compute the new value yourself from the mutation's response and write it straight into the cache for the affected key(s), no second request. The UI updates the instant the mutation resolves, but it's only as correct as your manual computation — get the write wrong and the cache silently disagrees with the server until something else happens to refetch it.

Neither one is "the right one" in general. Invalidate-and-refetch is the safe default; direct cache write is the optimization you reach for on a mutation that's hot enough, or latency-sensitive enough, to justify hand-writing the update.

See it in a real thing: liking a post

Both approaches acting on the same mutation, a POST /posts/:id/like that returns the post's new like count:

// Approach 1: invalidate-and-refetch
async function likePost(postId: string) {
  await api.post(`/posts/${postId}/like`);
  // Mark this key stale; the cache layer refetches it (and any
  // other query currently reading the same key) on its own schedule.
  cache.invalidate(["post", postId]);
}

// Approach 2: direct cache write
async function likePost(postId: string) {
  const res = await api.post<{ likeCount: number }>(`/posts/${postId}/like`);
  // No refetch — trust the response and write the new value ourselves.
  cache.setQueryData(["post", postId], (old) => ({
    ...old,
    likeCount: res.likeCount,
  }));
}

A user likes a post. The mutation request fires and the server processes it.

BackNext

The second version only works because the response actually contains likeCount. If the endpoint just returned { success: true }, a direct write would have nothing correct to write, and reaching for likeCount: likeCount + 1 off stale local state is exactly how the cache and the server quietly drift apart — that increment is only right if no other tab, device, or user changed the count in between.

What people usually miss

Watch out

• Invalidate-and-refetch isn't "worse," it's the correctness baseline. Reach for a direct write only when the round-trip delay is actually visible or costly enough to justify the extra risk — not as a default habit.
• A direct write is only as good as the response payload. If the mutation's response doesn't contain enough information to construct the true new value, a direct write is a guess, not a fact — this is the single most common source of a cache silently going stale.
• Invalidating one key doesn't cascade. Liking a post might need its own cache entry invalidated AND the paginated feed list that embeds a copy of that same post, depending on whether the cache is normalized or per-query — missing the second one leaves an inconsistent screen.
• "It updated instantly" isn't proof a direct write is correct. A wrong direct write also updates instantly — it just updates to the wrong value, and nothing will catch that until an unrelated refetch happens to overwrite it later.
• Invalidation timing matters. Invalidating before the mutation's request has actually resolved can trigger a refetch that races the mutation itself and reads a value from before the change landed.

Why this matters in interviews

"After this mutation succeeds, how does the UI actually end up showing the new data?" is a real follow-up to any caching discussion, and naming both strategies — plus the specific tradeoff between them — shows you've actually written this code, not just read about caching in the abstract.