fw-09 — Broader Ideas

Server state is a different substance

Shared, stale by default, mutated by actors you cannot see. Most frontend architecture mistakes at scale come from putting it in the same container as client state and then discovering that "refresh," "invalidate," "retry," and "who else changed this" have no meaning there.

The clean split — client state in a store, server state in a cache — is one of the highest-value architectural decisions available to a frontend team, and it is worth arguing for from mechanism rather than from library preference.

Monotonic counters beat clocks

The proof that timestamps fail for last-write-wins is short and complete, and it generalises to every distributed ordering problem you will meet: Lamport clocks, sequence numbers, and version vectors all exist because wall clocks disagree.

Any time you find yourself comparing timestamps to decide which of two events is newer, stop and ask whether a counter under one authority is available.

Optimistic UI is a contention bet

It trades correctness under concurrency for latency. Right for low-contention data, wrong for high-contention data — and "is this data contended?" is a product question that engineers routinely answer by default rather than by asking.

Rollback onto a moved base is the case that exposes it, and the three strategies have genuinely different costs.

Data format shapes client architecture

Most libraries chose document caches over normalised ones because REST responses have no reliable identity. GraphQL clients normalise because the format supplies __typename and id.

That is a strong, concrete example for any argument that API design has consequences far beyond the wire — useful the next time a backend team proposes a shape "because it is easier to serve."

Next

fw-10 is where cache, render cost, and the platform's own affordances meet in one component.