Apollo's normalized cache

What's really being asked

Whether you understand that Apollo does not cache responses as opaque blobs but normalizes them into a flat, shared entity store, and why that matters for consistency across screens.

The full answer

When a query returns, Apollo's InMemoryCache breaks the nested result into individual objects, computing a cache id for each from its __typename plus its id or keyFields. It stores these objects in a flat map and replaces nested objects with references, so any entity exists exactly once regardless of how many queries returned it. Because storage is by identity, a mutation or another query that updates that entity is reflected instantly on every screen reading it, with no manual refetch. Overlapping queries reuse cached entities, reducing network calls, and the cache can serve a query partly or wholly from memory.

The mistakes people make

Thinking Apollo caches each query's full response separately, which would duplicate shared objects and let copies drift out of sync; assuming entities without an id are still merged; or believing updates always require refetching. Forgetting that you must configure keyFields for types lacking an id is a practical gap.

What usually comes next

What happens to objects that lack an id field? How do you update the cache after a mutation that adds to a list? How do field policies and type policies customize merging? How does this compare to React Query's caching?

A concrete example

A feed screen and a profile screen both fetch User 7. Apollo stores User:7 once. When a mutation renames User 7, the single cache entry updates and both screens re-render with the new name immediately, no refetch needed. Without normalization, each query would hold its own copy, so the profile screen would keep showing the stale name until manually refreshed.