State normalization for relational data
modeling relational data in a flat store.
store entities by id in lookup tables, reference relationships by id, avoid nesting and duplication.
deeply nested arrays that force cascading updates and stale duplicates.
What's really being asked
Whether you treat the Redux store like a relational database rather than a snapshot of the UI. It probes your understanding of duplication, update cost, and consistency in large, interconnected state.
The full answer
Normalization means each entity type lives in its own lookup table keyed by id, with an accompanying array of ids for ordering. Relationships are expressed by storing foreign ids, not nested objects. This gives a single source of truth, so updating an owner touches one place instead of every item that embedded a copy; lookups and updates become direct id access; and components can select exactly the entities they need. It mirrors database design and pairs well with Redux Toolkit's createEntityAdapter, which generates normalized reducers and selectors.
The mistakes people make
Keeping deeply nested arrays for convenience, duplicating related data so edits go stale, or normalizing trivially small state where the overhead is not justified. Forgetting to also track ordering with an allIds array is a subtle gap.
What usually comes next
How does createEntityAdapter help? How do you re-denormalize for rendering, and where do you do that work? How do you handle many-to-many relationships?
A concrete example
Before: items is an array where each item embeds a full owner object, so owner Ada appears duplicated in three items. After: state.items.byId maps itemId to { id, title, ownerId }, state.items.allIds lists order, and state.users.byId maps userId to the single owner record. Renaming Ada updates one entry in users.byId, and every item referencing that ownerId reflects the change instantly with no duplication or stale copies.
Interview question
What is the main reason embedding full related objects inside each list item is discouraged in a normalized store?
- a.Nested data prevents useSelector from subscribing to the store at all
- b.Nested objects cannot be serialized to JSON for persistence
- c.Redux forbids storing objects deeper than two levels in the state tree
- d.Editing one entity then requires updating every duplicated copy, risking stale dataCorrect
Why? this is the answer
Duplicating an entity across items means a single change must be propagated everywhere, inviting inconsistency; normalization keeps one source of truth. Redux imposes no depth limit and nested objects serialize fine, so those options are false.
Just read this? Test yourself on what you have been reading.
Read the original → redux.js.org
- #redux
- #normalization
- #state-shape
- #relational-data
- #architecture
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on redux — each one lists the topics its interview covers.
See open roles