Vocabulary for Data Mesh Architects

Data mesh is a sociotechnical approach to data architecture that distributes ownership of analytical data to the teams that produce it. Introduced by Zhamak Dehghani in 2019, it has rapidly developed its own vocabulary that blends data engineering, domain-driven design, and platform thinking.

Understanding and using this vocabulary correctly is essential for data architects, data engineers, and platform teams working in organisations that are adopting or evaluating data mesh.

The Four Principles of Data Mesh

Data mesh is built on four foundational principles. Knowing these terms and being able to explain them fluently is the starting point for any data mesh discussion.

1. Domain Ownership

Domain ownership means that the team responsible for a business domain (e.g. Orders, Customers, Payments) is also responsible for producing and maintaining the analytical data for that domain — rather than centralising all data work in a single data engineering team.

“Under domain ownership, the Orders team publishes their own order events as a data product, rather than sending raw data to a central warehouse team to process.” “We’re shifting to domain ownership this quarter. Each domain team will be accountable for the quality and freshness of their own data products.”

2. Data as a Product

In data mesh, data sets are treated as data products — first-class assets with owners, consumers, SLAs, documentation, and quality guarantees.

“A data product is not a raw data dump — it should be discoverable, understandable, trustworthy, and interoperable.” “The Customer 360 data product is owned by the Customer Experience team. It has a documented schema, a freshness SLA of 15 minutes, and a data quality score published in the data catalog.”

3. Self-Serve Data Platform

The self-serve data platform provides the infrastructure and tooling that domain teams need to build, publish, and consume data products without needing specialist platform support for each task.

“The self-serve platform provides domain teams with templates for creating data products, automated schema registration, and a standard observability stack — all available without opening a ticket.” “Without a self-serve platform, every domain team would need to hire their own infrastructure specialists. The platform abstracts that complexity.”

4. Federated Computational Governance

Federated computational governance distributes policy-setting responsibility across domain teams while using automation to enforce policies consistently at scale.

“We use federated governance to allow each domain to choose its own storage technology, while the platform automatically enforces data encryption, access logging, and schema versioning across all data products.” “Federated governance means we set the standards centrally but enforce them computationally — no manual review required.”

Data Product Vocabulary

Data Contract

A data contract is a formal agreement between a data producer and a consumer that defines the schema, quality expectations, SLAs, and semantics of a data product.

“Before consuming the Orders data product, each downstream team must sign the data contract. If the producer needs to make a breaking schema change, they must notify all contract holders 30 days in advance.”

Schema Registry

A schema registry is a central store for data schemas (typically Avro, Protobuf, or JSON Schema) that ensures producers and consumers agree on data structure.

“All Kafka topics in our platform must have schemas registered in the schema registry. This enforces compatibility rules and prevents breaking changes from silently breaking consumers.”

Data Catalog

A data catalog is a searchable inventory of all data products, their owners, schemas, freshness, and quality metrics.

“The data catalog is the front door to our data mesh. Engineers browse it to discover what data products exist, who owns them, and whether they meet the quality standards for their use case.”

Interoperability and Standards

Interoperability

Interoperability in data mesh means that data products from different domains can be joined, combined, and consumed together, regardless of which team produced them.

“Interoperability requires that all data products use a standard set of global identifiers — for example, all products must use the same customer_id format so that cross-domain analysis is possible.”

Global Identifier

A global identifier is a common key used across all domain data products to link entities (e.g. a customer, order, or product) across domains.

“Without a global customer identifier agreed across domains, joining the Orders and Customer Behaviour data products would require brittle, custom mapping logic.”

Governance and Quality Vocabulary

Data Quality SLA

A data quality SLA defines the measurable quality commitments a data product owner makes to consumers — typically covering freshness, completeness, and accuracy.

“The Transactions data product has a freshness SLA of five minutes and a completeness SLA of 99.9%. These are monitored automatically and surfaced in the data catalog.”

Data Observability

Data observability is the ability to understand, monitor, and troubleshoot data health across pipelines and data products — analogous to application observability (metrics, logs, traces).

“Our data observability platform monitors schema drift, volume anomalies, and null rate increases across all data products and alerts the owning team when a threshold is breached.”

Practical Phrases for Data Mesh Architects

• “This is a domain data product — it should be owned and published by the Payments team, not by the central data platform.”
• “We need a data contract here before this consumer dependency becomes implicit and impossible to change.”
• “The self-serve platform reduces the barrier for domain teams to become data producers.”
• “Federated governance lets us set the guardrails once and enforce them everywhere — without manual review.”
• “The data catalog is the discovery mechanism for our mesh. If a data product isn’t in the catalog, it effectively doesn’t exist.”

Data mesh vocabulary reflects a fundamental shift in how organisations think about data ownership and architecture. Using these terms precisely enables clearer conversations across the boundary between data engineering, platform engineering, and the business domains that produce and consume data.