In a normalized client cache, what happens when two operations write the same entity with different values?

## One entry, many writers The premise of a normalized store is that an object lives in exactly one place. Every response that mentions it — a list query, a detail query, a mutation payload, a subscription message — writes into that one entry. This is not a side effect of the design; it *is* the design, and it is why the technique is worth its cost. But it also means an entity has many concurrent writers and no coordination between them. ## The merge rule Writing an object into the store is a shallow merge of the fields present in this response onto the fields already there. Fields the response did not carry are left alone — a response selecting three fields does not erase the other nine. Fields the response did carry replace what was there. There is no comparison of old and new: the write is unconditional. So for any field two responses both carry, the value in the store is whichever response was *written* last. Not requested last, not generated last on the server — written last on the client. ## Why arrival order is not request order In a warehouse inventory graph spread across an 11-service graph, one operation may resolve entirely from a hot in-memory service while another fans out to inventory, location and audit backends. Two screens open at once issue two operations; the second one issued returns in 40 ms and the first in 610 ms. The client writes them in that order. If both selected `Pallet.quantity`, the value that sticks is the one the *slower* response carried — computed earlier on the server, written later on the client. The user-visible effect is that the detail screen showing `236` briefly settles to `236` and then flips back to `231`, because a background list refresh landed afterwards carrying the older read. Nothing is broken in any single component; the coupling is in the store. ## Why this reaches screens nobody touched Client libraries track which active reads depend on which entity keys, so that a write can notify exactly the affected views. That dependency graph is the delivery mechanism for the consistency benefit — and it is also why an operation on one screen can visibly change another. A background refresh on a dashboard is not scoped to the dashboard; it publishes into the shared store and every mounted view reading those entities re-renders. This is the single biggest mental adjustment for someone coming from per-request caching. There, a component's data belongs to that component's request. Here, a component's data belongs to the store, and the component is a subscriber. ## The related trap: field sets of different fidelity A subtler version is not about timing but about fidelity. Suppose two operations both select `Pallet.status`, but one derives it from a lightweight summary service that reports only `IN_STOCK` or `MISSING`, while the other reads a richer service that also reports `QUARANTINED`. Both write the same field name on the same entity. Whichever lands last defines what the user sees, on every screen. The disagreement is a schema-design problem — one field name carrying two different meanings — but the normalized store is where it becomes visible, because it is the only place the two values ever meet. ## Diagnosing it The symptom is a value that reverts, flickers, or changes on a screen the user did not interact with. The method: 1. Identify the entity key and the field, not the component. The component is a symptom. 2. Enumerate every operation in flight or on a refresh interval that selects that field on that type. That set is your writer list. 3. Look at ordering, not correctness. Each response was probably right when the server produced it. ## What to do about it There is no single fix, which is why this is a judgement question. - **Reduce the writer set.** If only one operation is authoritative for a volatile field, keep that field out of the others' selections. A list that does not select `quantity` cannot stamp on it. - **Prefer server-computed truth on a single path.** Volatile counters are often better fetched by one dedicated operation than incidentally by five. - **Order deliberately where it matters.** Suppress or discard a stale in-flight response when a newer read of the same data has already resolved, rather than letting arrival order decide. - **Give the field a freshness signal.** If the schema exposes a version or an updated-at value on the entity, the client can be configured to ignore a write carrying an older one — but note this is per-type configuration you write, not behaviour a store provides by default. - **Do not reach for isolation.** Giving each screen its own store restores duplicate copies and stale views — you have paid for normalization and thrown away the reason for it. ## The honest summary for an interview Last-write-wins per field is not a defect in normalized caching; it is the price of a single shared truth on the client. Say that plainly, show you know arrival order is what decides, and then talk about narrowing who writes a volatile field rather than about adding a conflict-resolution engine to the client.