Data Mesh

Data Mesh is an organizational and architectural approach to managing analytical data across business domains. Instead of routing every ingestion request, transformation, and quality issue through one central data team, domains such as sales, payments, and logistics own and publish their data products. A shared platform supplies reusable capabilities, while enterprise-wide governance establishes rules that all domains must follow. Decentralizing ownership does not mean abandoning centralized security requirements.

A data product is more than a table or a collection of files. It has an accountable owner, documented business meaning, discoverable metadata, supported access interfaces, and measurable expectations for quality and freshness. For example, the payments domain might publish a daily settlements product with a documented schema, currency definitions, reconciliation checks, and a commitment to availability by a specified time. Consumers should understand how to request access, report defects, and prepare for breaking schema changes.

In the cloud, domains can operate in separate accounts, projects, or subscriptions while using shared provisioning templates and governance services. A platform team provides self-service capabilities for storage, pipelines, catalogs, identity integration, monitoring, and policy enforcement. Domain teams remain responsible for their products, but they should not need to build a separate security or deployment framework for each one. Physical separation is optional: multiple domains can also publish products from a shared lake or warehouse.

Federated computational governance combines enterprise-wide requirements with domain participation and automated enforcement. Common rules can cover sensitive-data classification, approved regions, encryption, retention, ownership metadata, and audit logging. Domain owners contribute business-specific definitions and access decisions within those boundaries. Policies should be enforced through deployment checks and runtime controls, not merely documented in a governance handbook.

Sharing patterns include governed access to producer-managed tables, warehouse data sharing, APIs, event streams, and controlled copies. Direct access can reduce duplication, but it requires compatible authorization and query mechanisms. Copies may support isolation or performance, but they introduce additional retention, deletion, and consistency obligations. Cross-account sharing still requires appropriate identity permissions, resource permissions, and, where applicable, encryption-key permissions. Catalog discovery or subscription approval alone does not necessarily authorize access to the underlying data.

Privacy requirements remain applicable across domain boundaries. A marketing team might receive a customer-segment product containing pseudonymous identifiers instead of names and email addresses. Access should be limited to approved purposes and necessary attributes, with row or column restrictions where supported. Pseudonymized data can remain personal data; it is not automatically anonymous. Retention and deletion processes must account for downstream copies, and access revocation does not erase data already exported by a consumer.

The trade-offs include more distributed operational responsibility, potential duplication, inconsistent definitions, and additional coordination for cross-domain joins. Shared identifiers, data contracts, quality checks, and clear ownership help manage these risks. Data Mesh is not a service, a service mesh, or simply a multi-account data lake. It can use lakes and warehouses, and a central platform team remains useful. In exam scenarios, look for domain-owned data products, reusable platform capabilities, and federated governance rather than assuming that decentralization means unrestricted sharing.