Overview#
Fabric solution patterns combine multiple capabilities around a business architecture rather than explaining a single workload in isolation. The recurring foundation is OneLake as shared storage, workspaces and domains as ownership boundaries, capacities as compute isolation, and cited workload choices for engineering, SQL, real-time, BI, and APIs [S1] [S2] [S3] [S4].
Pattern map#
Use a medallion lakehouse when data needs layered curation over Delta tables, Spark transformations, and SQL/BI serving over the same OneLake data [S2] [S5]. Use streaming analytics when events need a hot KQL path plus a OneLake cold path for downstream analysis [S6] [S7]. Use data mesh domains when organizational ownership, discovery, governance delegation, and capacity isolation matter more than a single centralized team model [S3] [S4] [S8].
Use warehouse migration when SQL teams need a warehouse-oriented target over Fabric storage and performance controls [S9] [S10]. Use multi-stack integration when the main challenge is combining shortcuts, mirroring, GraphQL, and pipelines around external systems without unnecessary copies [S1] [S11] [S12]. Use semantic layer strategy when the main decision is how to govern metrics, storage modes, Direct Lake, and Power BI consumption [S13] [S14].
How it works and best practices#
Pick the pattern from the dominant constraint. If the problem is transformation lifecycle, start with medallion. If it is event freshness, start with streaming. If it is ownership and chargeback, start with domains. If it is SQL modernization, start with warehouse migration. If it is app/API access, start with multi-stack integration. If it is metric consistency and report scale, start with semantic layer strategy [S2] [S6] [S8] [S9] [S12] [S13].
Every pattern should name its authoritative data product, its serving surface, its capacity boundary, and the places where inference is being used beyond verified claims [S1] [S4].
Implementation example#
Use a pattern selector before choosing tools. The selector below turns the dominant constraint into the starting architecture, then points to the deeper article for implementation detail [S1] [S2] [S6] [S8] [S9] [S13].
pattern_selector:
if_primary_constraint_is_layered_curation:
start_with: medallion_lakehouse
if_primary_constraint_is_seconds_fresh_events:
start_with: streaming_analytics
if_primary_constraint_is_sql_modernization:
start_with: warehouse_migration
if_primary_constraint_is_cross_system_reuse:
start_with: multi_stack_integration
if_primary_constraint_is_metric_consistency:
start_with: semantic_layer_strategy
if_primary_constraint_is_domain_ownership:
start_with: data_mesh_domains
Inference: this selector is an architecture triage tool. The sourced mechanics behind the branches are OneLake/lakehouse storage, Real-Time Intelligence, Warehouse, Mirroring/GraphQL integration, semantic models, and governance/domain/capacity constructs [S1] [S2] [S6] [S8] [S9] [S11] [S12] [S13].
Fabric Jumpstart can be used as a discovery path before implementation: install a relevant accelerator or tutorial into a sandbox workspace, inspect the Fabric items it creates, and use the result as a reference rather than as an automatic production baseline [S15].
import jumpstart
jumpstart.list()
jumpstart.install("name", item_prefix="pattern_eval_")
The Jumpstart flow is sourced to Microsoft's Fabric Jumpstart catalog and package behavior; production promotion still needs the article-specific governance and validation steps [S15].
What goes wrong#
Patterns fail when they are chosen by tool preference rather than constraints. A streaming architecture for daily refresh, a warehouse migration for semi-structured engineering workloads, or a data mesh without real domain ownership adds operating cost without solving the underlying problem [S2] [S6] [S8] [S9].
Internals#
Architecture & design#
Most Fabric solution patterns are compositions over the same platform primitives: OneLake storage, Delta tables, workload-specific compute engines, governance through Purview, and capacity-based compute isolation [S1] [S3] [S4].
How it works internally#
The internal mechanics differ by pattern: medallion depends on Delta transaction-log and file-layout behavior, streaming depends on Eventhouse hot/cold storage and OneLake availability, and semantic strategy depends on semantic model and Direct Lake column loading behavior [S5] [S7] [S13] [S14].
Performance characteristics#
The dominant performance lever changes with the pattern. Medallion depends on file layout and Spark execution, streaming depends on cache and batching choices, warehouse migration depends on SQL engine behavior, and BI strategy depends on semantic model memory and storage mode selection [S5] [S7] [S10] [S14].
Worked example#
A retailer might use medallion lakehouse for curated sales tables, streaming analytics for live store events, semantic layer strategy for governed KPIs, and data mesh domains for Finance and Operations ownership [S2] [S6] [S8] [S13]. Those patterns can coexist because they share OneLake, governance, and capacity concepts instead of creating separate platforms [S1] [S3] [S4].