Normalized vs Denormalized State: Cache Drift Simulator

Storage Model

Screens observing this entity 3

Auto-resync on read

Consistency

Stale copies

0 / 3

Consistency

100%

Max staleness age

0.0 s

How it works

An app screen can either hold its own copy of a piece of server/app state (denormalized), or reference a single canonical record in a normalized store (a "byId" entity table, as in Redux + normalizr, or a Room/SQLite entity cache).

Denormalized: Screen_i.value = copy stored at last read
Normalized:   Screen_i.value = store.entities[id].value   (always)

stale(i)      = 1  if Screen_i.value != canonical.value, else 0
consistency%  = 100 * (1 - Σ stale(i) / N)
maxAge        = max over stale screens of (t_now - t_diverged)

Dispatching an update mutates exactly one canonical entity. In the normalized model every screen reads that same entity, so stale(i) is always 0 — the pulse reaches every screen in one step because there is only one copy to update. In the denormalized model only the screen that was actually re-fetched (the active one) gets the new value; every other screen keeps showing its stale cached copy until it happens to re-read the data, which is exactly the "props say A, another screen says B" bug that state-normalization principles (single source of truth, immutable state, normalized shape) exist to prevent.

Auto-resync on read simulates a common workaround — polling or refetching stale screens on an interval instead of normalizing the store. It lowers the average staleness age but never reaches zero, because a new dispatch can always land in the gap between resyncs.

DENORMALIZED

Canonical entity (store) Synced screen copy Stale screen copy

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.