Several systems each hold a version of the customer record and they disagree. What is the architectural approach?

The approach

Name the system of record for each attribute, not for the entity. The entity rarely has one owner: identity may be owned by the identity provider, billing details by the finance system, employment attributes by the HR system, and preferences by the product.

Two authorities for one attribute produces permanent reconciliation work, and it is the state that most organisations arrive at by accident.

What follows from naming it

• Every other copy is explicitly derived, populated by a documented pipeline and rebuildable.
• Derive rather than dual-write, via change data capture or an outbox, so copies cannot silently diverge from the authority.
• A stable identifier that survives across systems, since matching on natural attributes — name, email — produces false matches and false splits, and both are damaging.
• A reconciliation process comparing derived copies against the authority, because divergence is inevitable and the only question is whether it is detected.

The hard part

The identifier. Systems adopted at different times have their own identifiers, and mapping between them is where the complexity lives. A mapping table maintained by matching rules will have errors, and the errors are asymmetric: a false merge combines two people's records and is far worse than a false split.

So the matching should be conservative, with ambiguous cases routed to human review rather than resolved automatically — and the review queue must have an owner or it becomes a backlog nobody clears.

What must not be attempted

A single golden record that every system reads and writes. It becomes a bottleneck, a single point of failure, and a coordination point for every system's release — and it fails because different systems genuinely need different attributes with different lifecycles.

Federated ownership with clear per-attribute authority is achievable; centralised ownership of the entity rarely is.

The workforce-platform specific risk

Deletion and deactivation propagate outward to many downstream systems. A safety threshold — refusing to process a deactivation batch above a proportion of the population without confirmation — is not optional, since an upstream fault returning an empty result is indistinguishable from everyone having left, and its absence has produced the most damaging incidents in this category.