Denormalization

Denormalization deliberately stores duplicate or precombined data to make common reads faster or simpler. It trades additional storage and write-side coordination for fewer joins, less computation, or a read model shaped around how clients query data.

A normalized design stores each fact in one authoritative place and connects related records with keys. A denormalized design may copy a fact into another record or store a precomputed result—for example, keeping a customer's name on each order so an order summary can be fetched without joining the customer table.

Key points

• Denormalization is a deliberate data-modeling trade-off, not an automatic improvement.
• It can reduce joins or repeated computation for frequent read patterns.
• Copied or precomputed values need a plan for updates, consistency, and repair.
• Choose what to duplicate based on measured workloads and acceptable freshness.
• Denormalization can be implemented in relational databases, caches, or separate read models.

Interview questions

What is denormalization, and why would you use it?

Denormalization deliberately duplicates or precomputes data in a model. It can make common reads faster or simpler by reducing joins or repeated calculations. The cost is extra storage and the need to keep copies consistent. I would consider it when a measured read workload justifies that cost.

How would you keep a copied customer name on an order up to date?

First, I would clarify whether the order should show the customer's current name or the name recorded when the order was placed. If it should track the current name, the update path must propagate changes to affected orders or the stored read model. Depending on the architecture, that could use a transaction, an event-driven update, or a rebuildable projection. I would also plan for retries, duplicate events, monitoring, and a way to repair missed updates.

When is eventual consistency acceptable for a denormalized read model?

It is acceptable when a short delay between a write and its appearance in reads meets the product's requirements. The system should make the freshness behavior clear and handle retries or repeated events safely. For operations requiring an immediate authoritative answer, the read should use a source or path that provides the required consistency. The decision is a product and correctness requirement, not just a performance setting.

How would you decide whether to denormalize a slow query?

I would first measure the query under representative data volume and traffic, and inspect its execution plan and access patterns. Then I would compare options such as indexing, query changes, caching, and denormalization, including their write and operational costs. If denormalization is justified, I would define the authoritative data, freshness contract, update path, and recovery process before rollout. I would monitor both read improvements and the added write or maintenance load.

What consistency risks arise when a write updates normalized and denormalized data?

The copies can diverge if one update succeeds and another fails, or if updates arrive out of order. A single database transaction may keep related writes atomic when they share a transactional boundary, but it does not automatically solve coordination across independent services or stores. For asynchronous propagation, durable event delivery, idempotent processing, ordering controls where needed, and reconciliation can reduce risk. The design should state which copy is authoritative and what stale reads are permitted.