Normalized vs Denormalized State: Cache Drift Simulator (2D)

Storage Model

Screens observing this entity 3

Dispatch rate (auto) 0 /s

Sync propagation delay 0.0 s

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 after the sync propagation delay elapses stale(i) returns to 0 for all of them — 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. The dispatch rate slider drives updates automatically instead of one click at a time, and sync propagation delay models the network/IPC round-trip before even a normalized store's update actually lands on every screen.

DENORMALIZED

Canonical entity (store) Synced screen copy Stale screen copy