Data Normalization: Organizing State for Performance
Data normalization transforms nested, hard-to-update state into flat lookup tables (entities by ID) and relationship arrays. This pattern dramatically improves performance, maintainability, and update predictability in complex applications like Kanban boards, social feeds, and e-commerce catalogs.
Entities are books stored on shelves by ID (O(1) lookup). Relationships are index cards pointing to book IDs. When you update a book, you only change it once — every index card automatically sees the update. No need to search through every shelf.
1Normalized Structure Pattern
Use three parts: lookup tables for entities, arrays of IDs for relationships/order, and separate UI state.
2Why Normalization Matters
Eliminates deep nesting, duplication, and complex immutable updates. Provides single source of truth and O(1) access.
3Real-World Examples
Kanban boards (issues by column), social feeds (tweets + comments), product catalogs (products by category).
| Property | Nested State | Normalized State |
|---|---|---|
| Access | O(n) search | O(1) by ID |
| Updates | Complex deep cloning | Simple & predictable |
| Use Case | Small/simple data | Large, relational data |
| Scalability | Poor with growth | Excellent |
Nested State
Access
O(n) search
Updates
Complex deep cloning
Use Case
Small/simple data
Scalability
Poor with growth
Normalized State
Access
O(1) by ID
Updates
Simple & predictable
Use Case
Large, relational data
Scalability
Excellent
Common questions
- ›“What is data normalization and why use it?”
- ›“How would you normalize a Kanban board state?”
- ›“What are the trade-offs of normalized vs nested state?”
- ›“How do you handle derived data in normalized state?”
What interviewers look for
- Understanding of performance and maintainability benefits
- Ability to show concrete before/after examples
- Knowledge of lookup tables + relationship arrays
- Awareness of when normalization is overkill
Short answer (60 sec)
Normalization stores entities in flat lookup tables by ID and relationships as arrays of IDs. This gives O(1) access, single source of truth, and simple updates — essential for large, frequently changing data.
Detailed answer (senior level)
Instead of deeply nested objects, keep entities in maps (issues, users, columns) and relationships as ID arrays (issuesByColumn, columnOrder). This eliminates duplication, makes updates trivial, and scales well. Use selectors or memoization to derive nested views when needed for rendering.
- Over-normalizing small/simple datasets
- Forgetting to update relationship arrays when entities change
- Not separating UI state from normalized data
- Deeply nesting derived data in the store
- Poor entity identity strategy (non-unique IDs)
- ✓Normalization = entities by ID + relationships as ID arrays
- ✓Provides O(1) access and single source of truth
- ✓Dramatically simplifies updates and reduces bugs
- ✓Excellent for Kanban, feeds, catalogs, and relational data
- ✓Use memoized selectors for derived/nested views
- ✓Skip for small or mostly read-only data
- ✓Combine with React Query for server state
Related web fundamentals topics
Continue with closely related browser and frontend engineering concepts.