When I work with master data, I assume duplicate truth already exists somewhere. I recommend designing matching, stewardship, and golden record publishing before dashboards start arguing with operational systems.
One trusted identity for core entities
Master data is not bigger reference data; it is the governed identity layer for entities the business cannot afford to confuse.
How golden records reduce disagreement
Master data is not bigger reference data; it is the governed identity layer for entities the business cannot afford to confuse.
Databases that fit this shape
MDM hubs, PostgreSQL, SQL Server, Oracle, DynamoDB or Cosmos DB for serving, Elasticsearch or OpenSearch for lookup, warehouses for analytics.
Cloud building blocks
| Provider | Typical services |
|---|---|
| AWS | AWS Glue, AWS Entity Resolution, RDS or Aurora, DynamoDB, OpenSearch. |
| Azure | Data Factory, Microsoft Purview, Azure SQL, Cosmos DB, Dynamics 365 Customer Insights. |
| Google Cloud | Datastream, Cloud SQL or Spanner, Dataplex, BigQuery. |
A known industry pattern
When I talk about "A known industry pattern", I am checking whether Master Data Architecture can be traced back, trusted, and used by someone making a decision.
The real world pattern is customer 360 in large retailers and banks: one person may appear in commerce, support, billing, and marketing systems, but the business needs one trusted customer view for service and compliance.
Where this shows up in real work
My recommendation in "Where this shows up in real work" is to keep the raw source close enough that the answer can be explained later.
A product master receives catalog records from merchandising, suppliers, and ecommerce. Matching rules create one product id, choose the approved product name, and publish the golden record to search, checkout, and reporting.
Query or pipeline example
I use "Query or pipeline example" to keep Master Data Architecture grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
merge into master_customer target
using staged_customer source
on target.golden_customer_id = source.golden_customer_id
when matched and source.quality_score > target.quality_score then
update set legal_name = source.legal_name,
email = source.email,
source_system = source.source_system,
last_verified_at = source.verified_at
when not matched and source.quality_score >= 90 then
insert (golden_customer_id, legal_name, email, source_system, last_verified_at)
values (source.golden_customer_id, source.legal_name, source.email, source.source_system, source.verified_at);The merge promotes only higher quality customer records and inserts new records only above a quality threshold. That protects the golden record from weak source data.
Watch these edges
- Separate matching logic from survivorship rules.
- Keep human stewardship for ambiguous merges.
- Publish master data changes like product APIs, not spreadsheet drops.