Apollo's normalized cache

WHAT THIS TESTS 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.

A GOOD ANSWER COVERS 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.

COMMON WRONG ANSWERS 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.

LIKELY FOLLOW-UPS 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?

ONE 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.