Momentum One Academy · article

Microsoft Fabric Architecture: From Services to Production Decisions

A Fabric proof of concept can be assembled in an afternoon. A dependable production platform takes longer because the hard questions are not “Which button creates a lakehouse?” They are “Who owns this data?”, “What may change without breaking a report?”, and “What happens when a refresh, notebook, and real-time workload compete for compute?”

At Momentum One Academy, we treat Fabric architecture as a chain of decisions. OneLake is the shared foundation, but it is not a design by itself. Lakehouses, warehouses, Eventhouses, workspaces, and capacities are boundaries with different operational consequences. The goal is a platform that can be understood, released, secured, and repaired by a team other than its original author.

Start with the production problem

A common failure pattern is to reproduce the old estate inside Fabric: one lake for every department, a workspace for every developer, duplicated extracts for every report, and a single capacity that absorbs every workload. The result may work in a demo but becomes difficult to govern. Data owners cannot tell which copy is authoritative. A “silver” table is overwritten by an ad hoc notebook. A report is fast until a large Spark job consumes the same shared compute. Nobody can explain whether a delay is caused by the source, the pipeline, the semantic model, or capacity pressure.

A production design begins with a service-level question. For example: “Every morning by 07:00, finance needs a reconciled revenue view, while operations needs sub-minute visibility into device failures.” Those requirements immediately imply different freshness, query, retention, and recovery expectations. They also suggest that batch analytics and event analytics should share governed data where useful, not necessarily use the same engine.

Document the data product before creating items. Record its owner, consumers, sensitivity, source-of-truth system, freshness target, acceptable downtime, expected growth, and approval path. This short contract becomes the test for every architecture choice below.

The Fabric map: platform, storage, items, and compute

Microsoft Fabric is a SaaS analytics platform with integrated experiences for data integration, engineering, data science, real-time intelligence, warehousing, databases, and Power BI. These experiences operate over shared platform services rather than requiring a separately integrated stack for each workload. 1

OneLake is the tenant-wide logical data lake. Every Fabric tenant includes one OneLake; teams organize ownership and access through domains, workspaces, and data items rather than provisioning a separate lake for every project. OneLake is built on Azure Data Lake Storage and uses open table formats, including Delta Parquet and Iceberg support described in the current documentation. 2 The practical implication is important: storage is a shared organizational asset, while the analytical item and its access policy express how a team uses that data.

A lakehouse is the flexible engineering and analytics item. It combines files and tables, supports Spark and SQL access, and automatically exposes a read-only SQL analytics endpoint for Delta tables. The lakehouse is a strong default when a team needs structured and unstructured data, notebooks, data science, or a medallion flow. Its SQL endpoint is not a full write-capable warehouse surface, so it should not be selected merely because analysts prefer SQL. 3

A warehouse is the better fit when the solution is SQL-first and needs relational modeling, multi-table transactions, views, stored procedures, or broader T-SQL write capabilities. Both warehouse and lakehouse data can remain in open Delta format in OneLake, so choosing a warehouse does not mean abandoning the shared storage model. 4

An Eventhouse with KQL databases is the deliberate choice for time-oriented event data such as telemetry, application logs, security events, or IoT streams. Microsoft describes Eventhouse as optimized for high-volume real-time analysis and semistructured or free-text data. It can contain multiple databases that share capacity and management. 5 Do not force a streaming workload into a batch-shaped lakehouse simply because the rest of the platform uses one.

A workspace is the collaboration and access container for items. It has granular roles—Admin, Member, Contributor, and Viewer—and can contain lakehouses, warehouses, reports, notebooks, pipelines, and other items. 6 Treat it as an ownership and lifecycle boundary, not as a casual folder. A workspace name should tell an operator what domain, layer, or environment it represents.

A Fabric capacity is a distinct resource pool in the tenant. Its SKU determines available compute, measured in capacity units (CUs), and workspaces are assigned to capacities for sizing and billing. 7 Capacity is therefore part of the production architecture: it affects concurrency, cost, and blast radius. It is not a substitute for efficient tables, sensible refresh design, or workload isolation.

Make the main architecture choices explicit

OneLake shortcut or a managed copy?

A OneLake shortcut is a reference to data in another OneLake location or supported external storage. It avoids duplication and presents the referenced files as available through the consuming item. 2 Use a shortcut when the source remains authoritative, near-real-time visibility matters, and the source owner can provide a stable contract.

Use a managed copy when the production product needs a controlled snapshot, independent availability, schema standardization, retention policy, or a recovery point that should not change when the source changes. The trade-off is storage and movement cost. The important distinction is ownership: a shortcut gives you a dependency; a managed Delta table gives you a lifecycle you control. Document that distinction in the data product contract.

One lakehouse, several layers, or separate workspaces?

Medallion architecture organizes progressive data quality into bronze (raw), silver (validated and standardized), and gold (curated for consumption). Microsoft’s Fabric guidance recommends implementing the layers through lakehouses in OneLake and keeping each layer separated, often with a separate workspace when stronger governance is needed. 8

Our production default is one workspace per environment and domain, with layer separation chosen according to ownership and risk. For a small workshop project, three lakehouses in one workspace can be easier to operate. For regulated or multi-team work, separate bronze, silver, and gold workspaces make access and release boundaries clearer. Do not split solely for visual neatness: every additional workspace adds permissions, deployment bindings, monitoring, and support work.

Keep bronze close to the source format and preserve the arrival context. In silver, standardize names, types, keys, time zones, and quality rules. In gold, publish business concepts rather than merely exposing every silver column. Delta tables are the usual choice for silver and gold because they support transactional behavior, schema enforcement, and time travel. 8

Direct Lake, Import, or DirectQuery?

For Power BI semantic models over Delta tables, Direct Lake can load data from OneLake without creating a second imported copy. Direct Lake on OneLake and Direct Lake on SQL have different behavior: Direct Lake on SQL can fall back to DirectQuery in cases such as SQL views or some source-side granular security patterns, while Direct Lake on OneLake does not use that SQL endpoint fallback. 9

This is a production decision, not a performance slogan. Test the actual semantic model, security design, refresh expectations, and capacity profile. A small curated gold model may be easier to govern with import. A large, frequently changing Delta model may benefit from Direct Lake. If the model depends on SQL views or a security feature that changes query behavior, make the possible fallback visible in the design review.

Where does KQL fit?

Use an Eventhouse when the primary question is “What has happened in the last few seconds or minutes?” Use a lakehouse or warehouse when the primary question is “What is the governed history and business definition?” A useful combined design ingests operational events into KQL for rapid detection, then writes selected, quality-checked history to OneLake for longer-term analysis. The systems can share a governed domain without pretending that one query engine is optimal for every latency target.

For example, assuming an Eventhouse KQL database has an AppEvents table with Timestamp and Level columns, this query gives an operator a one-minute error trend:

AppEvents
| where Timestamp > ago(15m)
| summarize Total=count(), Errors=countif(Level == "Error") by bin(Timestamp, 1m)
| order by Timestamp asc

The query is intentionally small. Production readiness still requires a defined event schema, clock and time-zone policy, retention decision, access model, and an owner for the alert or dashboard built on it.

An implementation path that survives handover

Name the outcome and contract. Define freshness, consumers, owner, sensitivity, recovery expectation, and the authoritative source. Avoid starting with a list of Fabric items.
Choose the serving engine. Select lakehouse, warehouse, Eventhouse, or a combination based on data shape, latency, transactions, and team skills. Record why the rejected options were rejected.
Design the OneLake layout. Decide what is stored, what is referenced with a shortcut, and what must be copied. Use consistent domain, environment, layer, and item naming. Keep raw arrival data immutable where it is the source of truth.
Make transformations repeatable. Validate schemas, quarantine bad records, make reruns idempotent, and separate business rules from ingestion mechanics. Avoid a notebook that silently overwrites a shared gold table without a contract.
Assign workspaces and capacity intentionally. Separate development, test, and production. Place workloads with similar ownership and service objectives together, and isolate noisy or mission-critical workloads when capacity evidence justifies it. Access should be granted through groups and workspace roles, with item- and data-level controls applied where required.
Release through source control and promotion. Fabric Git integration works at workspace level and supports versioning, collaboration, and branch-based work for supported items. Deployment pipelines provide development, test, and production stages so changes can be compared and promoted before users receive them. 10 11 Keep environment-specific connections and settings out of ad hoc notebook edits; parameterize them through the supported lifecycle approach.
Operate from evidence. Baseline pipeline duration, query latency, data volume, error rates, and capacity usage before calling the system production-ready. Write the runbook while the original team still remembers the design.

Failure modes to design out

The “one workspace for everything” trap: It makes discovery easy at first, but broad contributor access and mixed lifecycles make accidental changes likely. Start small if needed, but define the boundary you will split when ownership or risk diverges.

The “three folders equal medallion” trap: Naming folders bronze, silver, and gold does not create quality gates. Each layer needs explicit contracts, tests, lineage, retention, and an owner. A gold table built directly from an unvalidated source is still gold in name only.

The “shortcut means no operations” trap: A shortcut removes a copy; it does not remove source availability, permission, schema, or network dependency. Monitor the upstream owner and document the dependency.

The “capacity is infinite” trap: Fabric can burst and smooth workloads, but sustained overload still leads to delays and rejection. The documented throttling stages can first delay interactive operations, then reject interactive operations, and eventually reject new requests when future capacity is exhausted. 12

The “optimize by guessing” trap: Do not buy a larger SKU before identifying the consuming operation. The Capacity Metrics app provides health, compute, timepoint, storage, and item-level views; current usage data generally has processing latency, so it should be used for trend and diagnosis rather than treated as a live transaction log. 13

The “deployment equals data migration” trap: Deployment pipelines copy supported content between stages; they do not make every data movement, secret, external dependency, or backfill problem disappear. Test item pairing, settings, permissions, and post-deployment data actions explicitly.

Momentum One production checklist

Before a Module 1 architecture is approved, the team should be able to answer yes to these questions:

Is there one named owner and one source-of-truth decision for every published data product?
Does each lakehouse, warehouse, or Eventhouse have a documented purpose and consumer contract?
Are bronze, silver, and gold quality rules observable rather than implied by names?
Are shortcuts, copies, retention, and recovery points recorded as dependencies or owned assets?
Are workspace roles, data access, sensitivity, and environment boundaries reviewed by someone other than the builder?
Has capacity usage been measured under representative refresh, Spark, BI, and real-time concurrency?
Can a failed run be rerun without duplicating or corrupting the published result?
Can the team promote a change, roll it back, and identify which data and item versions are in production?
Does the runbook name the first dashboard, log, or metric an operator checks during an incident?

Workshop connection

In the Momentum One Academy workshop, this module is the point where a service catalogue becomes a production blueprint. Bring one real use case and draw four boundaries: the OneLake data path, the lakehouse or warehouse layers, the workspace and environment ownership, and the capacity allocation. Then defend each boundary against a failure scenario: a late source, a duplicate record, a permission change, and a capacity spike.

The workshop outcome is not a fashionable diagram. It is a decision record that a data engineer, analyst, security reviewer, and operations owner can all use. Continue the hands-on work in the Momentum One Academy Fabric production workshop.

References

Plan your workshop