NovOne property fact should not have five independent copies
Why a large property platform needs a shared source for prices, statuses and other facts that appear across many interfaces.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
Large sites duplicate facts almost by accident.
A price begins on a property page, then appears in search results, comparisons, calculators, saved lists and another language edition. While the site is small, manual updates can feel manageable. As the number of surfaces grows, each copied field becomes another place where yesterday's value can survive today's change.
A shared source is safer for the Thailand project catalogue and developer profiles than independent copies of the same status or price.
A source of truth has to be specific
“Keep the data centralised” is too vague to design around. I want to know which system owns each fact.
The project record might own the current asking price. A location registry might own the district. A verification timestamp may belong to an editorial workflow. Price per square metre, on the other hand, may be better calculated from price and area instead of stored as another editable number.
That distinction between source fields and derived fields matters. If area changes, any dependent calculation should change with it. If availability changes, every surface should consume the same state. A second hand-entered copy turns a simple update into reconciliation work.
Centralisation also does not require one giant database. Different domains can have different owners. The important part is that a field has an authoritative origin and that other interfaces do not quietly create their own versions.
Exceptions need names, not hidden overrides
The most fragile setup often starts with a reasonable request: show a different number in one component “just for now”. If that override has no explicit meaning, it becomes a second data source that nobody remembers six months later.
There are legitimate exceptions. A card may show a “from” price while a project page shows a range. A historical view may display the value verified on a particular date. Those should be modelled as different facts, not as silent replacements for the same field.
When two screens disagree, I want the system to make the reason discoverable. A developer should be able to trace each value to its origin instead of searching templates for a hard-coded number.
Consistency is not the same as truth
A technical system cannot tell whether the number supplied by an editor or developer is factually correct. It solves a different problem: once a fact has been approved, it should not fragment as it moves around the product.
That is why editorial verification and technical consistency belong together. A wrong source value can still propagate perfectly. A correct source value can still become misleading if copies drift apart.
For material fields, I like a release check that starts with one deliberate change and follows it across every relevant surface: project page, catalogue card, comparison, related modules and any language edition that reads from the same source.
The architecture is doing its job when one update produces one coherent reality, not five independently maintained versions of the same property.