The duplication problem
When responses are cached as nested blobs, the same entity can appear in many places: a user inside a list, inside a detail view, inside a comment. Update one copy and the others go stale. A normalized cache fixes this by storing each entity once, keyed by its id, and referencing it everywhere else.
- Each entity lives in a flat table by type and id.
- Lists and views hold references, not copies.
- One update touches the single source and fans out to all readers.
How normalization works
Normalizing a response means flattening nested objects into entity tables and replacing embedded objects with id pointers.
- Split a nested payload into separate maps per entity type.
- Keep a list of ids to preserve order.
- Resolve references when reading back to rebuild the shape.
When it is worth it
Normalization shines when entities are heavily shared and frequently mutated, like social graphs or collaborative apps. It adds complexity, so for mostly read only screens a document cache keyed by request is simpler and good enough.
Key idea
A normalized cache stores each entity once by id and references it everywhere, so a single update stays consistent across every view that shows that entity.