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.

Navigating the Nuances: A Practical Approach to Terminology

Let’s be honest – “data mesh” sounds impressive, but the terminology can feel overwhelming, especially when you’re used to a more centralized approach. As a non-native speaker, grappling with nuanced English in technical contexts can amplify that feeling. It’s not just about knowing the definitions; it’s about understanding how these concepts are discussed and applied in practice. A key difference is the emphasis on shared responsibility – “domain ownership” isn’t simply ‘owning your data’; it’s owning its use, its evolution, and ensuring it aligns with business goals within that specific domain. Similarly, “self-serve” doesn’t mean completely unattended; it implies a level of empowerment coupled with readily available support and documentation. Misunderstandings often arise from the subtle shifts in meaning between these terms – for example, “federated” isn’t just ‘loosely connected’; it describes a deliberate system of governance designed to balance autonomy with shared standards. When discussing interoperability, it’s not merely about systems talking to each other; it’s about ensuring meaningful exchange of value – data that is understood and utilized across domains.

Thinking through scenarios in English helps solidify understanding. Imagine a Slack conversation: “Okay, the Northwind team needs to update their customer schema. Can we get them to define a common address format using our interoperability standards so it aligns with the Finance domain’s expectations?” Notice the layered meaning – it’s not just about the schema change but also about adherence to standards and alignment across domains. During code reviews, phrases like “this data product needs more granular lineage” or “the API response should be documented using our standard schema” are incredibly important. Focusing on why a particular approach is being recommended – ‘to ensure traceability’ or ‘to facilitate integration’ – adds crucial context and helps you articulate your understanding effectively. It’s about actively listening for the underlying intent rather than just translating words.

Furthermore, be mindful of phrasing related to governance. Instead of simply stating “we need to enforce policies,” consider “we’re implementing federated computational governance to ensure consistent data quality across domains while respecting domain autonomy.” The latter emphasizes collaboration and shared responsibility, which is at the core of the data mesh philosophy. Don’t hesitate to ask for clarification – a simple question like, “Could you elaborate on what you mean by ‘consistent schema’ in this context?” can be incredibly valuable. Active listening and seeking clarification are key skills when navigating complex technical discussions.

Here’s an example illustrating how jq might be used to filter data based on a domain-specific attribute defined within a data product, reflecting the need for interoperability and domain-level control:

jq '.[] | if .customer_segment == "Retail" then .name + ": " + .email else empty end' data.json

This command takes a JSON file (data.json) and filters it to only include customer names and email addresses where the customer_segment attribute is equal to “Retail”. This demonstrates how domain-specific attributes are leveraged for targeted access and processing, aligning with the concept of self-serve data products.