Federated data-mesh domains on Microsoft Fabric

Goal#

Organise Microsoft Fabric so that several business domains each own and publish their own governed data products, share those products across the organisation without duplicating data, and are governed and billed with enough independence to make ownership real — while a central platform team retains tenant-wide policy, discovery, and compliance guardrails.

Framing note (inference). Data mesh is an organisational operating model — its four principles (domain ownership, data-as-a-product, self-serve platform, federated computational governance) are a framework, not Fabric features. This design maps those principles onto Fabric primitives. Wherever a sentence describes a Fabric mechanic it is claim-grounded and cited [Sn]; wherever it describes a mesh principle or a design choice it is labelled inference. This design deliberately carries more labelled inference than most, because the pattern itself is organisational.

Recommended architecture#

1. Map each business domain to a Fabric domain grouping its workspaces#

A Fabric domain lets an organisation group workspaces into a logical business area (for example Finance or Marketing), giving administrators a level above the workspace at which to delegate management and apply governance policies ^{[S1] [S5]}. Domains can contain subdomains, and workspace content can be filtered by domain in the OneLake catalog ^[S5].

Inference: This is the natural landing spot for mesh domain ownership — one Fabric domain per business area, with each domain owning the workspaces (and therefore the items) that hold its data products. Subdomains give a second level for large domains (e.g. Sales → EMEA/AMER) without inventing new constructs.

Inside a domain, model at least a producer/curated workspace (published, trusted items) and a development workspace (pre-publication work) — this separation is inference, but it aligns with the recommended capacity split below.

2. One tenant, one OneLake — domains do not get separate physical lakes#

Every Fabric tenant is provisioned with exactly one OneLake, with a single file-system namespace spanning users, regions, and clouds; the tenant maps to the root of the lake and workspaces act like folders beneath it, with lakehouses and other items inside workspaces ^{[S3] [S2]}. A tenant cannot create additional OneLake instances ^[S3].

This matters for mesh design: standing up separate physical data lakes per business group — a common pre-OneLake practice — is an explicit anti-pattern in Fabric, because it recreates the resource-management overhead and data duplication that a single tenant-wide OneLake with workspaces and shortcuts is designed to eliminate ^[S3].

Inference: A Fabric mesh therefore federates ownership and delegated policy, not storage. The physical lake stays shared; the domain boundary is an organisational and governance boundary drawn over shared OneLake, not a new storage silo.

3. Publish data products with certification; consume across domains with shortcuts#

Endorsement gives two trust signals: item owners can self-apply Promoted status, while the organisation can apply Certified status to items that meet defined quality standards; endorsed items get priority placement in certain search results and catalog views ^[S5]. The OneLake Catalog is a single searchable surface for every Fabric item a user can access, supporting domain-based and tag-based filtering so consumers reach relevant content without knowing which workspace holds the data ^[S5].

Inference: Endorsement + catalog is the Fabric realisation of data-as-a-product discoverability. Treat a Certified item in a domain's curated workspace as the published product; leave in-progress items Promoted or unendorsed.

Cross-domain consumption uses OneLake shortcuts, which are embedded references from a shortcut path to a target path in another location — behaving like a symbolic link — giving a lakehouse live, read-only references to data held elsewhere in OneLake (within a workspace, across workspaces, or even in other tenants via cross-tenant sharing) without duplicating the underlying data ^{[S4] [S6]}. Shortcuts are transparent to consumers: through the OneLake API they look like ordinary folders, so Spark, SQL, Real-Time Intelligence, Analysis Services, and non-Fabric ADLS-compatible apps can all query shortcut data with no shortcut-specific logic ^[S4].

Internal shortcuts can target other Fabric items across workspaces, and access through them is authorised with the calling user's own identity, which must hold read permission at the target ^[S4]. Shortcuts also reach external stores (ADLS, Amazon S3, GCS) as zero-copy references, with intelligent caching to cut cross-cloud egress ^{[S2] [S4]}, and can combine with cross-tenant data sharing so a domain can expose live governed data to another Entra tenant, read in place, with source-side policies still enforced ^{[S1] [S2]}.

Inference: A consuming domain builds its analytics on a shortcut into the producing domain's certified product. There is one physical copy, the producer stays the owner, and the consumer reads current data — the mesh's "consume, don't copy" contract falls out of shortcut semantics rather than needing a distribution pipeline.

4. Federate governance through the tenant → domain → workspace hierarchy#

Governance settings operate in a three-tier hierarchy: tenant-wide defaults set by Fabric admins, domain-level overrides applied by domain admins for delegated settings, and workspace-level controls managed by workspace owners for the most granular scope ^[S5]. Fabric organises its governance surface into four areas — managing the data estate (admin portal, domains, workspaces, capacities, metadata scanning), securing data (sensitivity labels, DLP, auditing), encouraging discovery and trust (OneLake catalog, endorsement, tags, lineage), and monitoring activity ^[S5]. Governance is centralised in the OneLake Catalog and powered by built-in Purview: permissions, sensitivity labels, and auditing are applied automatically and inherited across items, and stay enforced even when data is shared across tenant boundaries ^{[S5] [S2]}.

Inference: This hierarchy is federated computational governance: the central platform team sets tenant defaults (the guardrails), each domain admin owns delegated settings for its own domain, and workspace owners handle the finest scope. That is exactly the "global standards, local autonomy" split a mesh needs — expressed in product constructs, not a home-grown policy engine.

Governance in OneLake is hierarchical by construction: tenant-level security, compliance, and data-management policies automatically cover any data landing in OneLake, while workspaces distribute ownership and access ^[S3]. For sensitive domains (e.g. HR), sensitivity labels from Purview Information Protection can be applied manually or automatically and persist on exported data ^[S5]; DLP policies scan supported item types on upload and can alert data owners ^[S5]. Beyond workspace roles, data-level security (row-, column-, table-level) is available for SQL analytics endpoints, warehouses, Direct Lake, and KQL databases ^[S5].

5. Isolate cost and blast radius with a capacity per domain#

A capacity is a distinct resource pool inside an Entra tenant; the SKU sets its compute, a tenant can hold as many capacities as needed — often aligned to geography or business unit — and workspaces are assigned to a capacity ^[S7]. Capacities are the recommended isolation boundary for compute and chargebacks; the documented practice is to split capacities (for example by environment stage — dev/test/acceptance/production) to achieve workload isolation and cost attribution ^[S5]. Critically, Fabric enforces throttling at the capacity level, not the tenant level, so a saturated capacity only affects the workspaces assigned to it while other capacities keep operating normally ^[S8].

Inference: Give each domain its own capacity (and, per the stage-split guidance, its own dev vs prod capacities). This makes chargeback real — each domain is billed for its own pool ^{[S5] [S7]} — and contains blast radius: a runaway Finance job throttles only the Finance capacity, not Sales or HR ^[S8]. That capacity-level isolation is what lets domains be autonomous on cost and performance, not just on ownership.

Mind the F64 threshold when sizing: on an F64-or-larger capacity, users with only a free Fabric license can view Power BI content if they hold a workspace viewer role, whereas on smaller F SKUs every viewer needs a Pro/PPU license ^[S7]. For domains whose products are consumed broadly across the business, F64+ often pays for itself in viewer licensing ^[S7] (the sizing trade-off itself is inference).

Data flow#

1. A producer in a domain's curated workspace writes gold tables as Delta into its OneLake folder ^{[S2] [S3]} and Certifies the item as a published product ^[S5].
2. Consumers discover the product through the OneLake Catalog, filtered by domain and endorsement ^[S5].
3. A consuming domain creates an internal OneLake shortcut to the producer's item; the data is read live and in place, authorised with the consumer's own identity, with no copy ^[S4].
4. Reports/models in the consuming domain query the shortcut like a local folder ^[S4] and run on the consuming domain's capacity ^[S7].
5. Tenant-level Purview governance (labels, DLP, auditing) and compliance apply throughout, regardless of which domain reads the data ^{[S5] [S2]}.

Component responsibilities#

Central platform team (tenant scope) — owns tenant settings and global defaults, the Purview governance baseline (labels/DLP/compliance), the OneLake Catalog and endorsement policy, capacity procurement/standards, and the domain topology itself ^{[S5] [S7]}. (That this team owns exactly these is inference; the constructs it operates are claim-grounded.)

Domain team (domain + workspace scope) — owns its domain's workspaces and items, applies delegated domain-level governance overrides ^[S5], curates and Certifies its data products ^[S5], manages shortcuts into products it consumes ^[S4], and runs on its own capacity ^{[S5] [S7]}. (The ownership split is the mesh inference; the delegation and item mechanics are cited.)

OneLake (shared) — single physical lake for every domain, with workspaces as folders and shortcuts as the cross-domain sharing mechanism ^{[S3] [S4]}; enforces control-plane vs data-plane permissions on Entra identities ^[S6].

Performance#

Per-capacity throttling means each domain's peak load is smoothed and bounded within its own pool, so one domain's spike does not degrade another's ^[S8]. Fabric's compound throttling protection also ensures a single request that fans out across a chain (e.g. a report visual → semantic model → OneLake read) is throttled at most once per capacity in the chain ^[S8].

Inference: Because cross-domain reads go through read-only shortcuts to a single physical copy ^[S4], a mesh does not multiply storage or refresh cost the way copy-based distribution would; the main performance lever is right-sizing each domain's capacity SKU ^[S7].

Governance & security#

See section 4. In short: tenant defaults + domain overrides + workspace controls give federated governance out of product constructs ^[S5]; Purview labels/DLP/auditing and compliance certs are inherited and stay enforced across tenant boundaries ^{[S5] [S2]}; data-level (row/column/table) security is available on SQL endpoints, warehouses, Direct Lake, and KQL DBs ^[S5]. Note a sharp edge: OneLake security roles do not constrain workspace Admins, Members, or Contributors — those roles read/write all item data and bypass OneLake security, so granular roles only constrain Viewers and item-Read users ^[S6]. (Inference: keep producer-workspace membership tight so "read-only consumer" really means read-only.)*

Cost & capacity#

Capacities are the chargeback and isolation unit ^[S5]; align one (or a dev/prod pair) per domain, sized by SKU where Fn = n CUs and each step doubles compute ^[S7]. Watch the F64 viewer-licensing threshold for broadly consumed domains ^[S7]. The shared/default capacity hosts My Workspaces and Pro/PPU workspaces; new workspaces land there by default and can be reassigned to a domain's capacity ^[S7]. (Choosing where to draw the capacity lines and the chargeback model is inference; the capacity mechanics are cited.)

Risks & anti-patterns#

• Separate physical lakes per domain — do not. OneLake is one lake per tenant; per-group physical lakes recreate the duplication and overhead OneLake removes ^[S3].
• Assuming OneLake roles fence off producer teams. Admin/Member/Contributor bypass OneLake security; only Viewers/item-Read users are constrained ^[S6].
• Copy-based cross-domain sharing. Prefer zero-copy shortcuts to a certified product over pipelines that duplicate data ^[S4].
• Mesh premature (inference). If only one team truly owns the data, or departments lack the skills to own pipelines/quality, or there is no real chargeback requirement, federating into domains and separate capacities adds overhead with no ownership to match. Start centralized; carve out a domain only when a team genuinely owns a product. See the decision diagram below.

Alternatives#

• Centralized lakehouse (a). One team, one/few workspaces, one capacity, optionally a single domain for grouping. Lean here when curation ownership is central, policy is set centrally, and chargeback is not required — the mesh constructs would be overhead. (Inference, decision factors above.)
• Coexistence (b). Run most of the estate centrally and federate only the one or two departments that genuinely own products, each getting its own domain + capacity while the rest stays central. This is the common real-world middle path (inference) and is fully supported by the same constructs — you simply draw fewer domains.

Internals#

Architecture & design#

Domains sit above workspaces as a delegation and governance grouping ^{[S1] [S5]}; workspaces are collaboration containers that hold items, draw compute from a capacity, and control access ^[S1]. OneLake virtualises the whole tenant as one namespace with workspaces as folders and items as subfolders ^[S3], and shortcuts are embedded references (symbolic-link semantics) that make remote data appear local without copying ^[S4]. Governance is a strict tenant → domain → workspace tier stack ^[S5]. These are the load-bearing constructs a Fabric mesh is assembled from.

How it works internally#

OneLake security operates on two planes — a control plane (what users can do: create, manage, share) and a data plane (what data users can read, the OneLake security model) — and control-plane grants often confer data access by default ^[S6]. Shortcut reads use the calling user's own identity for internal targets ^[S4], while ADLS/S3 shortcuts delegate authorisation to a connection bound at shortcut-creation time ^[S4]. External query engines can register with OneLake and pull effective-access decisions to enforce table/row/column security at query time, keeping OneLake the single source of truth ^[S6]. Deeper engine internals of cross-domain query execution paths: Coming soon — no verified L5 claim yet covers the end-to-end execution path a shortcut-backed cross-domain query takes through the engines.

Performance characteristics#

Throttling is enforced per-capacity, so domains are isolated at the compute level ^[S8], and compound throttling charges a fanned-out request at most once per capacity in its chain ^[S8]. Shortcut caching keeps frequently used external data closer to compute and cuts egress, with configurable retention ^[S4]. Quantified cross-domain shortcut read latency and throughput benchmarks: Coming soon — no verified L4/L5 benchmark claim exists for shortcut-resolved cross-domain reads; do not infer specific numbers.

Assumptions#

• Departments named (Finance/Sales/HR) are illustrative; the pattern is domain-count-agnostic.
• The organisation is a single Entra tenant (hence a single OneLake) ^[S3]; cross-tenant mesh uses cross-tenant sharing ^[S2] and is out of primary scope.
• Each domain has the skills to own its own pipelines, quality, and semantic models — if not, prefer the centralized alternative (inference).

Open questions#

• Domain-to-capacity cardinality at scale. One capacity per domain vs shared capacities for smaller domains is a cost/isolation trade-off; no claim prescribes a limit, so size empirically.
• Product-contract/SLA metadata. Fabric endorsement signals trust ^[S5] but the KB has no claim on machine-readable data-product contracts/SLAs — if that capability is needed, refer to the knowledge-curator to source it rather than assuming a feature.
• Automated domain provisioning / policy-as-code. F-SKU workspaces expose ARM/Terraform ^[S7], but no claim covers end-to-end domain+policy provisioning as code; treat any such workflow as unverified until sourced.

Source legend#