Data Mesh

Data mesh is an approach to analytical data architecture that moves ownership of data from a single central team to the domain teams that generate it, and asks each of those teams to publish its data as a product with a documented interface, a named owner and a service level. It is primarily an organisational design; the technology underneath is mostly the same warehouses, lakes and pipelines used in centralised setups. The problem it responds to is a specific failure mode of the central data team. As a company grows, that team becomes a bottleneck: it owns pipelines for domains it does not understand, its backlog grows faster than its headcount, and when a source system changes nobody tells it, because the producing team does not know the pipeline exists. Quality suffers in a way that is structural rather than a matter of effort — the people who understand the data are not the people responsible for it. A mesh has four commonly cited principles: domain ownership of data, data served as a product, self-serve infrastructure, and federated governance. In practice the second and third do most of the work. Treating data as a product means the payments team publishes a payments dataset with a schema contract, discoverability metadata, quality expectations and someone accountable when it breaks — the same obligations a team would accept for an API. Self-serve infrastructure means a central platform group still exists, but builds the paved road rather than the pipelines: storage, orchestration, cataloguing, access control and monitoring that domain teams use without needing platform work for each new dataset. Federated governance keeps the cross-cutting rules — privacy classifications, retention, naming, interoperability — global while leaving the content local. Mesh is not a default. It carries real overhead and assumes domain teams have the engineering capacity and the appetite to run data products, which is often untrue below a certain size; a well-run central team is usually the better answer for a smaller company. Practical note: adopt it incrementally by making one high-traffic dataset a proper product first — contract, owner, SLA, documentation — and see whether the producing team can sustain it before restructuring anything.