Data Mesh

Data Mesh

Domain-oriented data products + self-serve platform + federated governance.

Why it matters

Data mesh treats each domain as a producer of one or more data products — same discipline as microservices, applied to analytics.

Going deeper

The four mesh principles, with the failure mode each one addresses:

1. Domain ownership — the team closest to the source owns the data product. Fixes: central team becomes a translator with stale context.
2. Data as a product — datasets ship with discoverability, addressability, trust, interoperability, security, self-describing semantics. Fixes: 'mystery tables nobody trusts'.
3. Self-serve platform — a paved road for ingest, transform, catalog, access, observability. Fixes: every team reinventing the same wheel.
4. Federated computational governance — standards encoded as platform checks, not PDF policies. Fixes: decentralisation degrading into chaos.

The classic anti-pattern: 'we're doing data mesh' = 'we renamed teams but the platform and the governance still don't exist'. Without principles 3 and 4, principle 1 just creates many small data monoliths.

Data mesh is what microservices did to monoliths, applied to analytics.

For a decade the monolith was the default — one codebase, one deploy, one team bottleneck. Microservices flipped it: small teams own bounded contexts end-to-end, a platform team paves the road, and a thin set of standards keeps everyone interoperable.

The 'central data team owns every pipeline' model is the data monolith. It bottlenecks the same way: long queues, fading domain knowledge, dashboards no one trusts. Data mesh moves data product ownership to the domain (checkout, catalogue, fraud), gives each domain a self-serve platform, and keeps standards federated rather than centrally policed.