Introduction
Most introductions to Microsoft Fabric describe it as “a unified analytics platform.” That framing is accurate but functionally useless for a data engineer trying to understand how data flows between components, where compute runs, how storage is billed, and what the right design patterns are for production workloads.
This post covers the Microsoft Fabric architecture at the level of specificity that engineering teams need — not the marketing overview, but the actual mechanics of OneLake, Fabric experiences, Delta Lake defaults, capacity-based compute, and how the pieces connect.
OneLake: The Foundation Everything Builds On
OneLake is the logical foundation of Microsoft Fabric. It is a single, unified, tenant-wide data lake built on Azure Data Lake Storage Gen2. Every workspace in Fabric gets a OneLake path. Every Fabric experience — Data Engineering, Data Science, Data Warehouse, Real-Time Analytics, and Power BI — reads from and writes to the same OneLake, without replication or movement.
This design eliminates the data silo problem at the storage layer. In a traditional Azure data architecture, data in a Synapse dedicated SQL pool, a Data Lake Storage account, and a Power BI dataset were three separate copies of related data. In Fabric, a Lakehouse table created by a Spark notebook is the same Delta Lake file that a Fabric Warehouse can query using T-SQL, and the same file that a Power BI Direct Lake semantic model reads directly from storage without import.
The Shortcut mechanism extends OneLake’s reach to external storage. A Shortcut creates a virtual path within OneLake that references data in Azure Data Lake Storage Gen2, Amazon S3, or Google Cloud Storage without physically moving the data. This means Fabric workloads can operate on external data as if it were local OneLake storage — which is significant for organizations with existing data lake investments that are not yet ready to migrate.
Fabric Experiences: The Compute Layer
Fabric’s compute is organized into “experiences,” each designed for a specific workload type. Understanding the boundary between experiences prevents misarchitecting solutions.
Data Engineering is the Spark-based experience for large-scale data transformation, pipeline development, and Lakehouse management. Notebooks and Spark Job Definitions run against Fabric Spark pools. Data written here lands in Delta Lake format in the Lakehouse’s Tables folder in OneLake.
Data Warehouse is the T-SQL experience for structured analytics. It uses a distributed query engine optimized for SQL workloads, and data is stored in Delta format in OneLake — not in a separate SQL pool as in Synapse. This means a Warehouse table can be read by a Spark notebook in Data Engineering without any ETL between them.
Data Science provides notebooks, experiments, and ML model management using MLflow. Data Scientists can directly reference Lakehouse tables from their notebooks, training models on data that data engineers have already curated.
Real-Time Intelligence handles streaming data ingestion and KQL (Kusto Query Language) analytics through EventStream and Eventhouse components. This is where Fabric handles IoT, telemetry, and event-driven data patterns.
Power BI is the BI and reporting experience. Direct Lake mode is the key architectural innovation here: Power BI can read Delta Lake files in OneLake directly from storage without importing data into an in-memory dataset. This delivers near-real-time reporting on Lakehouse data without the refresh cycle delay of traditional import mode.
Delta Lake and the Medallion Architecture Pattern
All structured data in Fabric Lakehouses is stored in Delta Lake format by default. Delta Lake brings ACID transaction support, schema enforcement, time travel queries, and incremental processing to parquet-based storage. The Medallion Architecture — Bronze, Silver, Gold layers representing raw, cleaned, and business-ready data — maps naturally to the Fabric Lakehouse model.
In a Fabric Medallion implementation: the Bronze Lakehouse receives raw data from ingestion pipelines (Data Factory or EventStream). A Silver Lakehouse stores cleansed and conformed data produced by Spark notebooks reading from Bronze. A Gold Lakehouse or Fabric Warehouse stores aggregated, business-ready tables consumed by Power BI Direct Lake reports.
Each layer is a separate Lakehouse in the same or different Fabric workspaces, with Shortcuts used to reference upstream layer data without copying it. The entire pipeline runs within Fabric’s unified capacity model, and all layers share the same OneLake storage.
Capacity-Based Compute: How Billing Works
Fabric’s compute model is capacity-based, not per-service. You purchase Fabric capacity (measured in Capacity Units, or CUs) and all Fabric experiences in that capacity draw from the same pool. A Fabric F64 capacity is a common enterprise starting point.
This model differs from Synapse’s per-pool billing. In Synapse, a dedicated SQL pool, a Spark pool, and a pipeline run are billed separately. In Fabric, a notebook run, a warehouse query, and a pipeline execution all draw from the same capacity budget, and capacity scales up or down based on the Fabric capacity SKU you select.
Capacity smoothing (Fabric bursting) allows workloads to consume more than their instantaneous capacity allocation by borrowing from future capacity headroom, preventing throttling during temporary spikes. Understanding this behavior is important for capacity planning — sustained over-utilization will cause throttling, not just temporary peaks.
Conclusion
Microsoft Fabric’s architecture is coherent once you understand that OneLake is the storage foundation, experiences are compute layers that read from and write to the same storage, and Delta Lake is the universal table format that makes cross-experience interoperability possible. The capacity model simplifies billing relative to managing multiple Azure services, but requires careful sizing to avoid throttling on production workloads.
Need a Microsoft Fabric Development implementation designed for production from day one? Prism Analytics builds enterprise Fabric solutions across the full stack. Let’s talk.