Precomputation and Denormalization

Overview

Precomputation moves work from read time to write time, or to a scheduled job. Denormalization is the storage side: keeping redundant copies of data so queries need no joins.

How it works

order placed ──> orders table (source of truth)
      │
      └─ event/CDC ──> updater ──> customer_totals(customer_id, order_count, revenue)
                                   product_page_doc(product_id, price, rating, stock)

An updater consumes changes and maintains the read model. Increments should be idempotent: store the last processed event id or recompute from the source for the affected key. A nightly or weekly rebuild corrects any accumulated drift.

Choose the approach by freshness need. In-transaction updates give immediate consistency but couple write latency to the number of derived copies. Change-data-capture pipelines add seconds of delay with no impact on the writer. Batch jobs are cheapest and suit reports and rankings.

Precompute only what is hot. Measure the top queries by cost times frequency, then build projections for those. Everything else can stay on the normalized model, where flexibility is worth more than speed.

Pitfalls

• Duplicating data without declaring a single source of truth.
• Non-idempotent counters that double count on retries.
• No reconciliation job, so errors persist for months.
• Denormalizing early. Premature copies are hard to remove.
• Updates that fan out to millions of derived rows, for example renaming a popular entity.

Key takeaways

• Keep one authoritative model and treat projections as rebuildable.
• Update derived data idempotently and reconcile regularly.
• Match the update mechanism to the staleness users can accept.
• Precompute only measured hot queries.