NovA cache should not preserve an old price after the source has changed
Why a fast property page is still wrong when cached copies keep an outdated price alive across search, comparison or saved-property views.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
A buyer does not experience “a caching issue.” They experience a property that appears to cost one amount in the catalogue, another on the project page and perhaps a third amount in a saved shortlist. From their perspective, the platform has stopped describing one offer consistently. The technical cause matters to the team, but it does not reduce the seriousness of the contradiction.
Caching is useful precisely because the same information does not need to be rebuilt or fetched on every request. Reusing a stored response can reduce latency and network work. That benefit becomes a product problem when the lifetime of the stored copy is longer than the acceptable lifetime of a material fact. A neighbourhood description and a current asking price do not necessarily deserve the same freshness policy.
The first question is which value the product considers current
When an old price is discovered, the instinctive response is often “clear the cache.” That may remove the visible symptom, but it does not answer the more important question: where does the current value come from, and which parts of the product depend on it?
A property platform can show the same commercial fact in many places. The catalogue may use it for a card. A comparison view may use it for a column. A saved-property view may store a snapshot. A calculator may depend on it indirectly. The Russian and English editions may render the same underlying record through different components. None of those surfaces should quietly become an independent source of truth just because it is convenient to cache the result.
The architecture does not need to be simplistic. Different services and layers can exist. What matters is that the system knows which value is authoritative for the present state and which rendered copies must react when that value changes.
Freshness is a product decision before it is a cache setting
HTTP standards define when stored responses can be reused, when they are considered fresh and how they can be revalidated. Those rules explain the mechanics of caching; they do not decide how much staleness a property buyer should be asked to tolerate for a particular field.
A current price deserves a stricter product decision than a paragraph that changes once a year. Availability, payment terms, promotional deadlines and material inclusions may also need shorter freshness windows. A platform can still be fast without pretending every field has the same tolerance for delay.
This is why I would not describe performance and correctness as competing goals in isolation. A page that loads instantly with a materially outdated number has delivered the wrong result efficiently. Optimisation is successful only when it preserves the meaning the user is relying on.
When current data cannot be confirmed, the state should change
A difficult case appears when the source has changed but one downstream surface cannot refresh successfully. Continuing to present the old figure as unquestionably current is often the worst outcome, because the interface gives the buyer no reason to doubt it.
There are several honest alternatives. The product may temporarily show that the price needs confirmation. It may show the last known amount with a clear date and a warning that the current figure is pending. In a high-risk context it may remove the number from a decision flow until the current state is available. The right choice depends on what the system genuinely knows.
The important distinction is between “the last value we had” and “the current value.” Those are not always the same statement. A technical failure should not collapse that distinction.
A generic “updated today” label is not enough either. If the page was rebuilt today using yesterday’s cached price, the label creates a stronger false impression. Dates are useful only when they refer to the data state that matters.
Fixing one page is not the same as fixing the buyer journey
Once the project page shows the correct figure, the incident can look finished. A buyer may still reach the old value through a saved item, comparison, translated edition or a previously generated view. If those paths still present the amount as current, the contradiction remains.
A sensible post-fix check follows the dependency of the fact. It starts with the source and then verifies only the places where that price genuinely appears or affects a decision. This is not a demand to refresh every page on the site after every edit. It is a demand to understand where the material field travels.
The same review should make sure an unavailable value has not been “repaired” by converting it to zero. Zero is a real number with its own meaning. Unknown, temporarily unavailable and zero are different states, and downstream filters or calculators will behave differently if they are confused.
Good caching disappears; trustworthy state remains visible
The buyer should not need to understand edge caches, revalidation or invalidation. Those mechanisms belong behind the interface. What should remain visible is the status of the commercial fact itself.
My practical standard is simple: once the authoritative price changes, every place that continues to present that field as current should either receive the new value within the agreed freshness window or clearly stop claiming that the old value is current. A buyer should never have to decide which screen to trust.
Caching earns its place by making the product faster without changing its meaning. When a stored copy outlives the fact it represents, the system has crossed that boundary. In property, where a price can determine whether a buyer even opens the next page, stale certainty is more damaging than an honest temporary unknown.
Sources
- IETF — RFC 9111, “HTTP Caching”, June 2022: defines HTTP cache storage, freshness, reuse and revalidation. Accessed 6 October 2026.
- NovAsia — Alexander Elshin expert profile: describes his technical role across platform architecture, data relationships, performance and error correction. Accessed 6 October 2026.