data-mesh-design

name	data-mesh-design
description	Design a data mesh architecture with domain ownership, data products, and federated governance. Outputs domain decomposition, data product contracts, self-serve platform requirements, and migration plan.
argument-hint	["number of domains","current data platform","team structure","regulatory requirements"]
allowed-tools	Read, Write

Data Mesh Design

Data mesh is a sociotechnical approach where domain teams own and serve their data as products, governed by federated standards and enabled by a self-serve data platform. It solves the centralised data team bottleneck that emerges in large organisations with many data-producing domains.

Use data mesh when: You have 5+ distinct business domains, a central data team is a bottleneck, domains have mature engineering teams, and data ownership is contested or unclear.

Don't use data mesh when: Small organisation (<100 engineers), single product, data team is not yet a bottleneck, or engineering maturity is low.

Four Principles

1. DOMAIN OWNERSHIP
   Data is owned by the domain that generates it.
   The Orders team owns and serves orders data as a product.
   Not: central data team ETL-ing from Orders DB.

2. DATA AS A PRODUCT
   Each domain publishes data products with:
   - SLAs (freshness, availability, quality)
   - Versioned schema contracts
   - Self-service discovery and access
   - Ownership and support contact

3. SELF-SERVE DATA PLATFORM
   A platform team provides infrastructure that makes it easy
   for domains to build and serve data products.
   Domains should not need data engineering expertise to publish.

4. FEDERATED COMPUTATIONAL GOVERNANCE
   Central standards (classification, access control, quality)
   enforced by automated policy — not central approval workflows.