Data freshness

Reading the whole inventory is a full scan, and every screen that leans on it would otherwise pay for that scan again. Two layers of memory sit on top of each other instead, which is why a screen can be showing data a few minutes old.

Layer	Where it lives	Window	What it holds
Browser	In the open tab, per user	Five minutes	Whole-set reads
Server	Shared by every user	A few minutes, set at deployment	The unfiltered read only

The layers stack rather than replace each other: the first saves network and parsing per tab, the second saves the database work for everyone.

What is never cached

• A search. A new question always gets a new read.
• Demo data. A momentary source failure must not pin demo rows in front of every user for the length of the window.
• Anything on disk. Nothing is stored locally in the browser, so reloading the page starts clean.

The button

Every screen that reads a whole set carries a refresh button in its toolbar. Its tooltip is the entire answer:

• "Updated N min ago · Refresh data" — the age and the action together.
• While it runs it spins and is disabled. A second click mid-refresh would only queue a duplicate read.
• The age is recomputed every thirty seconds, so a page left open for an hour does not keep claiming it was just updated.

A screen built from several reads shows the age of the oldest of them. One press crosses both layers.

A write clears both

Saving drops what it changed from both layers. Without that, a note saved on one screen would stay invisible on another until the window lapsed — which reads exactly like "my save did not work".

Databases — a screen that behaves differently

The databases screen reads straight from its source and is not part of the shared memory. It has a refresh button of its own and prints the time of the read instead of an age. When the source is unavailable it says so in an amber note and shows demo data — see Troubleshooting.