The four principles of data mesh get quoted constantly. The sentence that decides whether they apply to your company gets quoted almost never, and it is in the same article.
What it was arguing against
Data mesh was not a product launch. It was an argument, made by Zhamak Dehghani in May 2019, against three specific failure modes of the centralized data lake — and the three are worth reading closely, because they set up everything else.
Centralized and monolithic. Every source in the enterprise flows into one platform owned by one team, which becomes the bottleneck for every new source and every new consumer.
Coupled pipeline decomposition. The architecture is divided by pipeline stage — ingest, cleanse, aggregate, serve — rather than by business domain. The consequence, in her words, is that “the whole pipeline i.e. the monolithic platform, is the smallest unit that must change” when you want to add one thing.
Siloed hyper-specialized ownership. The data engineers sit between the teams that produce the data and the teams that consume it, holding the context of neither.
Read those three again. Not one of them is a complaint about technology. Every one is a statement about where the people sit — which is the whole idea, and the part that gets lost when data mesh is described as an architecture.
The four principles, and what each one asks of you
Dehghani formalized them in December 2020. The full names matter, because the short versions drop the argument:
1. Domain-oriented decentralized data ownership and architecture. The team that produces the data owns serving it — not “provides an extract on request”, but owns the pipeline, the schema and the quality.
What it asks: every domain needs somebody who can own a pipeline. Not a stakeholder who cares about the data. An engineer who can be paged about it.
2. Data as a product. A dataset with an interface, a documented contract, versions, and a name attached to it. Consumers build against the contract; breaking changes arrive as a new version rather than as a surprise on a Tuesday.
What it asks: someone willing to be the product owner of a table, and a team culture where you version instead of editing in place.
3. Self-serve data infrastructure as a platform. The common machinery — storage, pipeline orchestration, streaming, cataloguing, access control — is built once and centrally, so that no domain has to rebuild it.
What it asks: a platform team whose customers are the other teams. This is the principle organizations quietly skip, and skipping it is precisely what turns a mesh into a pile.
4. Federated computational governance. Rules decided jointly across domains and enforced by code rather than by review: PII tagging, access policy, retention, automated compliance checks.
What it asks: governance that executes. A policy document in a shared drive is not federated computational governance, however federated the committee that wrote it was.
The prerequisite nobody quotes
Dehghani is direct about who the argument is for. Writing about the centralized model in 2019, she says it “can work for organizations that have a simpler domain with smaller number of diverse consumption cases” and that it “fails for enterprises with rich domains.”
That is the sentence. Data mesh answers a problem you have to actually have. And the 2020 article assumes a company that is already decomposed along business domains — the mesh mirrors an organization that exists. It does not create one.
So before the four principles, there is one question, asked three times for each domain you are planning to hand data to:
- Name the domain.
- Name the person inside it who can own a pipeline.
- Name who consumes its output and would notice a breaking change.
Fill all three for several domains and the principles have something to attach to. Fill the first and not the second, and decentralizing ownership does not distribute it — it deletes it. The central team stops being the bottleneck and becomes nobody, which is worse, because a bottleneck at least has a queue you can see.
If your company is not that company
Most are not, and that is not a failing. The useful thing about the four principles is that they come apart, and the second one survives entirely on its own.
You can treat your three most-argued-over tables as products starting this quarter: an owner by name, a written contract, a version number when the shape changes, and a definition everyone has agreed to. None of that requires decentralization, a platform team, or the word mesh appearing in a slide.
What does not survive alone is the first principle without the third. Handing pipelines to domains before building the shared platform is the most common way this fails, and it fails in a specific way: you have distributed all of the work and none of the leverage, so every domain rebuilds ingestion, transformation and scheduling in parallel, each one slightly differently, each one badly.
The takeaway
Data mesh is not a layer you add or a tool you buy. It is an argument that data ownership should follow the organization chart instead of cutting across it — which is right when the chart has real domains behind it, and expensive theatre when it does not.
Read the four principles as four questions about your company rather than four features of a platform. The company answers first, and the architecture follows.
Originally published on datablast.io in December 2023. Rewritten September 2026.
See it on your own data
20 minutes, your questions, a live walkthrough.