Client-Side Data Cache

A client-side data cache sits between your components and the network. Ask for 'user 42' twice and the second ask is answered from memory instead of firing a second request, and two components asking at once collapse into one trip. It does not mean the network is touched once and never again: the same cache still revalidates in the background, refetches on your command, retries failures, and drops entries when you invalidate them. Libraries like TanStack Query, SWR, Apollo, and RTK Query key each response by the request that produced it, then share that one copy with every component asking for it.

The usual policy is stale-while-revalidate: hand over the cached copy instantly so the screen paints, then quietly refetch in the background and swap in fresh data if it changed. That is why a well-cached app feels instant when you navigate back to a page you already visited. Reach for it the moment two screens need the same server data, or the same screen is mounted and unmounted often.

The real trap is invalidation. After a mutation (create, edit, delete) the cache still holds the old answer, so the list you just added to looks unchanged. Every cache library gives you a way to mark keys dirty after a write, and forgetting to call it is the single most common bug. Second trap: a cache is not global state. Do not stuff form drafts or UI toggles into it.