INTERMEDIATE · 12 MIN · FREE LESSON
Denormalization trade-offs
Explore denormalization trade-offs through a visual, step-by-step model.
Loading interactive lesson…
INTERMEDIATE · 12 MIN · FREE LESSON
Explore denormalization trade-offs through a visual, step-by-step model.
Loading interactive lesson…
Orders hold a duplicate of the current customer address in denormalized mode. This is explicitly a current-profile cache, not an immutable historical shipping address. Normalize to read the authoritative customer at query time, or propagate updates to duplicate fields. Synchronous atomic fan-out rolls back a failed update; split writes can leave stale copies; asynchronous propagation uses a durable-intent assumption and bounded workers. Repair rebuilds copies from current truth.
Loading architecture diagram…
Choose whether the address means current profile data or a historical order fact before choosing a storage model.
The read model trades extra storage/write amplification against avoiding a join. Historical snapshots are a different domain rule and should not be rewritten as current-profile caches.
Model row writes, seed 42. Plotted sample sizes respect each lesson’s explicit input limits.
Keyboard: Space play/pause · ←/→ step · R restart · 1–5 speed. Reduced motion disables transitions.
A faster read can create many places where a customer update must stay consistent.
Inspect the relation or dependency state, then follow each validated decision. Use presets first; custom JSON preserves the displayed schema and bounds.
The normalized read follows Order.customerId to the authoritative current customer address. The denormalized read uses a duplicate address stored in each order. An update then requires fan-out writes. Compare synchronous atomic fan-out, unsafe split writes, and a durable asynchronous propagation queue. A failed split update can leave mixed versions; an atomic failure rolls back the profile and every copy.
Fail after one copied row, read two orders, and repair the stale copies. Compare normalized reads and asynchronous propagation with workers unavailable. Repair drains obsolete tasks before rebuilding current copies. Predict the next constraint, match or dependency decision before advancing.
The player names its measured operation and reports the core model cost. Separate fixture construction and index maintenance from the operation being measured; the displayed assumptions name each bound. These are teaching algorithms, not real database latency benchmarks.
Four language references implement the core mechanism over validated example data. The reference containers illustrate the declared model scope; real persistence, distributed coordination, recovery and provider limits require their own implementation. The interactive prose identifies baseline references or additional player experiments explicitly.
Read-heavy materialized views where storage and maintenance work are justified by measured query needs.
This address is explicitly current-profile cache data. A historical shipping-address snapshot is an immutable order fact and must not be rewritten when a customer moves. Atomic preflight is a deterministic teaching assumption; production fan-out needs real transactions or an outbox with ordering and reconciliation.
Explain a valid result, name the governing invariant and distinguish logical semantics from a physical implementation.
MAKE IT STICK
Progress saves on this device and merges with your account after sign-in.
0 / 5000 · Saved on this device; synced when signed in.