Skip to content

PATTERN Cited by 1 source

Mutation-aware sparse revalidation

After a mutation completes, revalidate only the data classes that mutation could have changed. Pair this with an optimistic overlay so an unchanged response does not become a mandatory follow-up fetch merely to repeat a state the client already knows. The alternative—refresh every related resource after every mutation—turns a narrow user action into a broad invalidation fan-out.

Method

  1. Classify mutations by affected domain data, not endpoint location.
  2. Preserve client-visible intent optimistically.
  3. Invalidate or fetch only read models whose contents could have changed.
  4. Let unrelated catalog/configuration data retain its cached version.
  5. Reconcile the overlay with the relevant authoritative read when it is available.

Seen in

  • sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack — adding a session to a user's schedule initially refreshed sessions, speakers, agenda items, and settings. Atlassian changed to mutation-aware revalidation: adding a relationship does not modify the session catalogue, so the optimistic overlay was sufficient for most mutations. “Add to schedule” calls decreased from 11 to 5.
Last updated · 619 distilled / 1,953 read