# Denormalization > Denormalization means deliberately storing duplicate or derived data so common reads need less work. In system design interviews, it is a way to avoid expensive joins, repeated aggregation, or cross-service lookups, but you must explain how the extra copies stay correct. Source: https://sysround.com/concepts/denormalization Updated: 2026-11-05 ## How denormalization works Start with the read you need to serve. A normalized restaurant model might keep restaurant details and individual reviews in separate tables; showing a restaurant's average rating requires aggregating its reviews. A denormalized model can store rating_sum and review_count alongside the restaurant so that read no longer scans reviews. Choose exactly what to duplicate or precompute. Common forms include copying an author's display name into a post record, embedding related records in a document, maintaining per-user feed entries, and storing aggregate counts. Keep only the fields that materially simplify the target query. Define the authoritative data and the meaning of each copy. Individual reviews can remain authoritative while restaurant rating totals are derived. Also distinguish a copy that should track current data from an intentional snapshot, such as the shipping address recorded when an order was placed. Choose an update path. If the source and derived fields share a transactional database, update them in one transaction when practical. Across stores, an outbox or change data capture can reliably feed asynchronous updates; then specify acceptable lag, retry behavior, and protection against duplicate or out-of-order events. Plan for repair, not just normal updates. Derived data should usually be rebuildable from authoritative records. Monitor update lag and mismatches, handle edits and deletions, and make sure a background rebuild cannot overwrite newer changes. ## Worked example: Precomputing restaurant ratings Suppose a restaurant has 1,000 reviews totaling 4,200 stars. Instead of aggregating those reviews on every page request, store rating_sum = 4,200 and review_count = 1,000; the displayed average is 4.2. When a review changes from two stars to five, update the review and add three to rating_sum in the same database transaction. Deleting a review subtracts its current stars and decrements the count. If a separate search index also stores the average, publish changes through an outbox and apply versioned updates there. Search results may briefly lag, but the database remains authoritative. Periodically recompute totals from reviews to detect and repair drift. ## Trade-offs - **Cheaper reads, more work on writes.** Precomputed results avoid repeated joins or aggregation, but each source change may require updating many derived records. - **More storage and larger records.** Duplicated fields consume space and can increase network traffic, index size, and backup costs. - **Consistency becomes explicit.** Transactional updates can keep copies synchronized within a transaction boundary, while asynchronous updates introduce lag that the product must tolerate. - **Update contention can move elsewhere.** A precomputed counter or summary can become a hot write target even when it makes reads inexpensive. - **Read models fit specific queries.** A layout optimized for one access pattern may require another projection or a costly migration when query requirements change. - **Repair and deletion become harder.** Every additional copy adds places to reconcile, rebuild, or remove data when source records change or disappear. ## When to use it in a system design interview - A frequent, latency-sensitive read repeatedly joins or aggregates the same data, and indexes or query changes are not enough. - A request must combine data across shards or services, making runtime lookups expensive or unreliable. - The system needs a purpose-built read model, such as a home feed, restaurant rating summary, or search document. - Reads substantially outnumber relevant updates, and the write fan-out and storage costs are acceptable. - The requirements allow a defined amount of staleness, or the necessary copies can be updated within one transaction. ## How to bring it up in the interview - Name the query before proposing the model: 'The restaurant page needs the rating and review count without scanning every review.' Show the source records and the derived fields. - Estimate both sides of the exchange: reads avoided, extra bytes stored, and copies updated per source change. Interviewers often probe whether a popular entity turns the write path into a bottleneck. - State the consistency contract field by field. A stale display name may be acceptable; a stale authorization decision or inventory total may not be safe to trust. - Explain the full update lifecycle: creation, edits, deletion, duplicate events, and out-of-order delivery. Expect questions about a crash between committing the source and updating the projection. - Describe how to detect drift and rebuild safely while writes continue. Defend denormalization against simpler options such as an index, a better query, or a cache. ## Common mistakes - Saying that SQL means normalized data and NoSQL means denormalized data; either database family can store denormalized models. - Duplicating fields without deciding which record is authoritative or whether the copy represents current state or a historical snapshot. - Writing to the source database and a second store independently, with no reliable handoff or repair plan. - Handling inserts but forgetting edits, deletes, retries, and events that arrive out of order. - Assuming denormalization always requires eventual consistency, or that a derived read model is safe for enforcing strict business invariants. ## Interview questions where it comes up - [Design a news feed like Facebook](https://sysround.com/questions/design-news-feed): Fan-out on write builds per-user feed records ahead of reads, trading cheaper feed retrieval for write amplification and update propagation. - [Design Instagram](https://sysround.com/questions/design-instagram): Home-feed construction requires deciding what to copy into feed entries and how publication, deletion, and follow changes affect those copies. - [Design a restaurant review app like Yelp](https://sysround.com/questions/design-yelp): Precomputed rating summaries and searchable restaurant documents must stay correct across review edits, deletions, and retries. - [Design Facebook likes at scale](https://sysround.com/questions/design-facebook-likes): Displayed like totals are derived from authoritative user-post state and require replay-safe updates and reconciliation. ## FAQ ### What is the difference between normalization and denormalization? Normalization separates facts into related tables to reduce duplication and update anomalies. Denormalization deliberately duplicates facts or stores derived results to make particular queries cheaper. A system can keep a normalized source of truth alongside denormalized read models. ### What is the difference between denormalization and caching? Denormalization describes how data is modeled; caching describes keeping a reusable copy to avoid fetching or computing it again. A denormalized table can be a durable part of the database with no expiration, while a cache commonly has eviction or expiry behavior. A cached feed or summary can be both. ### When should you avoid denormalization? Avoid it when an index or a simpler query already meets the latency target, or when frequent changes make maintaining copies too expensive. Be especially careful when stale copies could violate permissions, financial constraints, or inventory limits. A denormalized view can help discovery without being authoritative for the final action. ## Related concepts - [Materialized views](https://sysround.com/concepts/materialized-views) - [CQRS](https://sysround.com/concepts/cqrs) - [Change data capture](https://sysround.com/concepts/change-data-capture) - [Eventual consistency](https://sysround.com/concepts/eventual-consistency) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.