Data mesh architecture

Teams move to a data mesh when a central data team has become the bottleneck for the whole company. Every new dataset waits in the same queue, and the engineers building the pipelines know the least about what the data means. A mesh hands ownership to the teams that create the data.

What are the four principles of a data mesh?

1. Domain ownership. The team that runs a business area, such as claims, owns its analytical data as well as its systems.
2. Data as a product. Each dataset is published for other people to use, with an owner, documentation, quality checks and a commitment to keep it working.
3. Self-serve data platform. A platform team provides storage, pipelines, cataloging and access control as a service, so a domain can publish a product without building infrastructure.
4. Federated computational governance. Domain and platform representatives agree a small set of global rules, and the platform enforces them in code.

What are the parts of a data mesh architecture?

The diagram at the top of this page shows a mesh at an insurer.

• Domains. Business areas with their own teams and systems: policy, claims and finance.
• Data products. The unit of the mesh. policies, claims and loss_ratio are each owned by one team and consumed by others.
• The platform. The grey band at the bottom. One set of tools that every domain uses.
• Governance. The band at the top: shared identifiers, security classifications and quality standards.
• Consumers. Other domains, analysts and models, who find products in the catalog and read them through published interfaces.

What is a data product?

A data product is more than a table. It bundles the code that builds the data, the data itself, the metadata that describes it and a contract that states its freshness, quality and access rules. Data arrives through input ports and leaves through output ports, which may be a SQL table, a set of files or an event stream.

Type	Built from	Example
Source-aligned	One operational system	policies, claims
Aggregate	Several data products	customer_360
Consumer-aligned	Other products, shaped for one use	loss_ratio for finance reporting

A product is worth publishing only if it is easy to find, has a stable address, can be trusted, describes itself, works with other products and is secure.

How do you read a data mesh architecture diagram?

Read the hero diagram one column at a time. In the policy domain, the team runs the policy admin system and publishes policies from it. The claims team does the same with the claims system. The arrows between products show reuse: claims reads policies, and the finance domain’s loss_ratio is built from both.

Then read the bands. Every domain builds on the same platform, so nobody runs a private stack, and the governance band applies to every product. The structure will look familiar from microservices architecture: the same idea of small teams owning what they build, applied to analytical data.

The diagram raises the questions that decide whether a mesh works. Who is the named owner of each product? What happens to loss_ratio when the claims team renames a column? Can a new domain publish without help from the platform team?

How does a data mesh compare with a centralized data platform?

	Centralized lake or warehouse	Data mesh
Owner of the data	A central data team	Domain teams
Unit of delivery	Tables in one store	Data products with contracts
Bottleneck	The central team’s backlog	Platform maturity and domain skills
Governance	Applied by the central team	Agreed together, enforced by the platform
Fits	A few domains and one data team	Many domains, each with engineers

A mesh does not replace storage. Its products usually live in a data lake or a data warehouse, often the same one as before. A data fabric is the technology-led alternative, and the two can be combined.

How do you adopt a data mesh?

1. Check that you have the problem. A mesh answers a scaling problem. If the central team is keeping up, keep it.
2. Start with two or three domains. Pick ones with engineers and a willing owner.
3. Define a data product. Agree the minimum: an owner, a schema, documentation, quality checks and a freshness commitment.
4. Build the platform thin. Templates for a pipeline, a catalog entry and access rules are enough to start.
5. Agree the global rules. Common identifiers, data classifications and how access is requested.
6. Measure use. Count the consumers of each product and the time it takes to publish a new one.
7. Draw the mesh. An architecture diagram of domains, products and their consumers shows who depends on whom.

What are common data mesh mistakes?

• Renaming the central team. If one team still builds every pipeline, nothing has changed.
• Domains without engineers. Ownership without the skills to act on it produces neglected products.
• No platform. Each domain builds its own stack and the silos return.
• Products nobody uses. Publish for a known consumer, not for completeness.
• Governance by committee. Rules that are not automated are not followed.

What tools help with a data mesh?

• Data platforms and catalogs. A shared lake or warehouse with a catalog where products are registered, searched and requested.
• Data contracts and quality tools. Schema definitions and tests that run in each product’s pipeline and fail the build when a contract is broken.
• AI diagramming tools. Tools like Eraser turn a description of your domains, data products and platform into an architecture diagram you can keep editing as text, which helps when the map of products changes every quarter.

For more on this kind of diagram, see architecture diagrams.

Frequently asked questions