Guide ยท Last reviewed: September 2026

Domain mesh topology

Federated by domain. Full autonomy, full responsibility.

Each business domain owns its complete data stack: engineering, analytics, and everything in between. A domain might use Starter, Split, or Hub and spoke internally, but the key principle is that each domain operates independently. Domains share data with each other through well-defined contracts, typically shortcuts into each other's Gold layers.

Finance

  • Pipelines
  • Gold layer

Sales

  • Pipelines
  • Gold layer

Supply chain

  • Pipelines
  • Gold layer

Marketing

  • Pipelines
  • Gold layer

Shared, not owned

  • Naming and certification
  • Access and tenant policy
Four peers and no centre. Each domain runs its own stack and publishes a Gold layer the others shortcut to, so the only shared thing is the standard every domain agrees to meet.

Why teams move here

This is the data mesh model applied to Fabric workspace design. There's no central platform team owning all pipelines; each domain acts as both producer and consumer. The trade-off is coordination at scale: without strong governance standards, you risk inconsistent quality, duplicated effort, and a fragmented experience for cross-domain reporting.

Pros and cons

Pros

  • Domain autonomy. Each domain controls its own tools and pace, without waiting for a central team to prioritise its requests.
  • Scales with organisational structure. New domains spin up their own workspaces without queueing behind a central platform team.
  • Clear accountability. Each domain owns the quality, security, and availability of its own data products.
  • Fit-for-purpose design. Finance might need tight controls; Marketing might need speed. Each domain optimises its own topology.
  • Resilience through independence. A pipeline failure in one domain doesn't cascade to the others.

Cons

  • Governance complexity. Maintaining consistent standards for naming, security, and quality across independent domains takes deliberate effort. Without it, you get chaos.
  • Cross-domain reporting is hard. A report spanning Finance, Sales, and Marketing data needs shortcuts across multiple domains and alignment on schemas and refresh timing.
  • Duplication risk. Without visibility, two domains can build similar pipelines or models independently, losing the efficiency of shared assets.
  • Skills distribution. Every domain needs people who understand data engineering, not just analytics. A domain lacking that capability struggles.
  • Discovery challenges. Finding what data exists across the organisation gets harder without a data catalogue or similar mechanism.

Where this fits

  • Large enterprise with distinct business units. Finance, HR, Supply Chain, and Sales operate as semi-independent units, each with its own budget, priorities, and data team. Centralising would slow all of them down for little gain.
  • Global organisations with regional autonomy. EMEA, APAC, and the Americas each operate their own data platform, sharing global reference data while building regional analytics independently.
  • Data mesh adoption. The organisation has committed to domain ownership, data as a product, and self-serve infrastructure, and Domain mesh is the natural Fabric implementation.
  • Acquisitions or mergers. An acquired company keeps operating as a separate domain while standards gradually align, rather than forcing immediate integration.

When this doesn't fit

  • The organisation is too small to justify the overhead, under roughly 50 people working with data
  • Cross-domain use cases dominate, and most reports need data from multiple domains
  • Domains lack the skills or budget to run their own engineering
  • There's no governance framework to ensure consistency across domains

If cross-domain integration is your primary use case, a Hub and spoke model with shared ownership may serve you better than a full mesh.

Considerations

  • Establish governance standards early. Define naming conventions, security baselines, data quality expectations, and documentation requirements every domain must follow.
  • Invest in a data catalogue. When data is spread across domains, people need one place to look up what exists.
  • Define data product contracts. Each domain exposing data to others should document what it provides: tables, refresh cadence, schema stability, and support model.
  • Create cross-domain forums. Regular syncs between domain leads surface duplication and align on standards.
  • Monitor at the tenant level. Individual domain monitoring isn't enough; you need tenant-wide visibility into capacity, security, and compliance.