Data Mesh Principles

Data mesh (Zhamak Dehghani) is a response to the bottlenecks of centralized data teams. Instead of one central team owning a monolithic warehouse/lake, ownership is decentralized to the domain teams who understand the data best. It rests on four principles: domain ownership, data as a product, a self-serve data platform, and federated computational governance. The shift is as much organizational as technical — moving from a central data team that becomes a bottleneck to domain-aligned ownership at scale.

Data as a product means each domain treats the data it publishes as a first-class product serving internal consumers. A good data product is discoverable (findable in a catalog), addressable, trustworthy (with quality SLAs and freshness guarantees), self-describing (documented schema and semantics), and interoperable (standardized formats). It has a product owner accountable for its quality and roadmap. This reframes data from a neglected exhaust of operations into something teams deliberately design, document, and maintain for their consumers.

Federated computational governance resolves the tension between domain autonomy and organization-wide consistency. A federation of domain representatives defines global policies — privacy, security, interoperability standards, naming conventions — while domains retain autonomy over their own data products. Crucially, governance is computational: rules are encoded into the platform and enforced automatically (policy-as-code, automated quality checks, access controls) rather than relying on manual review boards. This lets governance scale without becoming the bottleneck that data mesh exists to eliminate.

A data contract formalizes the interface between a data producer and its consumers, much like an API contract. It specifies the schema, field semantics, allowed values, freshness/quality SLAs, and ownership. Critically, it is enforced: CI checks validate that a producer's change does not violate the contract, catching breaking changes (a dropped column, a type change) before they silently break downstream pipelines and dashboards. Data contracts are a key enabler of data-as-a-product, giving consumers stable guarantees and producers clear expectations.

A data SLO applies reliability-engineering thinking to data products. Just as a service has latency/availability SLOs, a data product commits to measurable guarantees: freshness (how recent the data is), completeness (no missing partitions), accuracy/validity (rows pass quality checks), and availability. Consumers can depend on these guarantees, and breaches trigger alerts and accountability. This makes data quality a tracked, owned commitment rather than a vague hope — essential for treating data as a trustworthy product.