Topic 7.7
Denormalization
In one line
Deliberately duplicating data for read speed — the moment SQL conversations step into system design.
Think of it like this
Keeping a printed summary sheet pinned to the office wall so people don't have to walk to the filing room and dig through folders every time they need last month's totals. It's faster to read, but someone must remember to update the wall sheet whenever the folders change.
Key ideas
- 01
The pattern: pre-join, pre-aggregate, pre-count — write redundant columns/rows to make the hot read one lookup.
- 02
Examples: order table carrying user_name snapshot; product table carrying review_count; summary tables for dashboards.
- 03
The price is sync: updates must touch every copy — batch jobs, events, or triggers keep them coherent.
- 04
Read-modify-write patterns on counters get race-prone — see Phase 10 caching, Phase 13 CQRS.
- 05
Denormalize where the read:write ratio is high; keep canonical data normalized and derive hot reads.
- 06
In HLD answers: 'orders are denormalized for read APIs; the canonical write model stays in Postgres; a Kafka event keeps copies in sync'.
Java / Spring map
- →
Spring: event listeners update denormalized tables transactionally; or read models via projections (CQRS-lite).
Explain without notes
Invent a denormalized column for the parking-lot dashboard and describe the sync mechanism that keeps it honest.
Practice
Pick your LLD's hottest read and show the denormalized storage + the update path.
Trade-offs
- ↔
Freshness lag vs join cost: denormalization guarantees bounded staleness, never zero — say the bound out loud.
Completion checklist
I treat denormalization as a deliberate, synchronized trade — not a data-modeling mistake.