What Is Data Mesh? Principles, Architecture and Examples
What is data mesh? Its four principles, how domains share data products without copying, federated governance, data mesh vs lakehouse, and when to use it.
In a large company, one central data team serving every department becomes a bottleneck: finance, sales, marketing and HR all queue for the same engineers, and the central team never understands each domain's data as well as the domain does. Data mesh flips the model: each business domain owns its data, publishes it as a product other teams can discover and consume, and a shared platform plus common rules keep it all interoperable.
The four principles
| Principle | What it means in practice |
|---|---|
| Domain ownership | The team that produces the data (e.g. the payments team) owns its pipelines, quality and access, instead of handing raw data to a central team |
| Data as a product | Each published dataset has an owner, documentation, a schema contract, SLAs (freshness, quality) and is easy to discover. See data contracts |
| Self-serve data platform | A platform team provides storage, compute, catalog, access control and templates so domains don't each rebuild infrastructure. See internal developer platforms |
| Federated computational governance | Global rules (naming, PII handling, interoperability standards) are agreed centrally but enforced automatically in the platform, while domains govern their own data day to day |
How it looks on a cloud platform
Instead of one cloud account for everyone, each domain gets its own account. A producer account holds a domain's data and publishes it; a consumer account in another domain can query that data without copying it; a central governance account holds the data catalog (the metadata about every published dataset and who may use it).
On AWS this is typically separate accounts per domain, with a central AWS Glue Data Catalog and Lake Formation permissions for cross-account sharing; Databricks Unity Catalog and Snowflake data sharing offer similar "share, don't copy" mechanisms. Zalando, the European fashion retailer, is a well-known adopter: separate accounts for ingestion and serving, plus a central account holding metadata about all storage.
Centralized platform vs data mesh
| Centralized data team | Data mesh | |
|---|---|---|
| Who builds pipelines | One central team for everyone | Each domain for its own data |
| Bottleneck | The central team's backlog | Domain skills and consistency across domains |
| Data knowledge | Second-hand | With the people who produce the data |
| Sharing | Copies into a central warehouse | Query in place through a catalog |
| Governance | Central and manual | Federated: global rules, enforced by the platform |
| Fits | Small and mid-size organizations | Large organizations with many domains |
Data mesh is an organizational change more than a technology. It needs domain teams with data skills, a solid self-serve platform and real governance; without them you get many inconsistent data silos. Most companies with a handful of data consumers are better served by one well-run lakehouse.
Where it’s used
Domains such as orders, logistics and marketing each publish data products.
Domain ownership with strict, platform-enforced governance for regulated data.
Independent business units share data without a single central bottleneck.
Cross-account catalogs and permissions (Glue + Lake Formation, Unity Catalog, Snowflake sharing).
In an interview
- Raise data mesh when the problem is organizational scale (many domains, a central bottleneck), not data volume.
- Name the four principles and the producer / consumer / central catalog layout.
- Be honest about the cost: it needs mature domain teams and a strong platform.
Frequently asked questions
What is data mesh?
Data mesh is an approach where each business domain owns its data and publishes it as a product for other teams to use, supported by a shared self-serve platform and common governance rules, instead of one central data team owning everything.
What are the four principles of data mesh?
Domain ownership, data as a product, a self-serve data platform, and federated computational governance.
When should a company use data mesh?
When many domains depend on a central data team that has become a bottleneck. Smaller organizations are usually better served by one well-run lakehouse or warehouse.