DP-600 Fabric Architecture: From Storage to Insight

An analytics architecture is easy to draw as a tidy sequence of boxes: ingest, store, transform, model, report. The real system becomes complicated when one team owns the source database, another owns the lakehouse, and a third discovers that numbers in the board report changed after a deployment. A sound design does more than move records. It establishes the meaning, custody, performance expectations, and security of data as it moves between teams. For DP-600, those tradeoffs are more valuable than memorizing a preferred diagram.

Consider a multinational retailer with a point-of-sale system, a product catalog, an e-commerce event stream, and finance adjustments. Sales leadership wants regional metrics by morning, while operations wants near-current activity. Both use some of the same source data, but they do not have identical freshness or access requirements. Designing this solution in Microsoft Fabric starts with choosing where each responsibility belongs and where a shared semantic definition should be established.

Let access patterns decide the analytical layers

Begin with the questions people will run. A transactional history query that scans several years of order lines behaves differently from a dashboard refreshing current stock movement. Write down source update frequency, acceptable reporting delay, typical query shape, concurrent users, retention needs, and what must remain auditable. These details determine whether to materialize an aggregate, expose a detailed Delta table, or stage data for a semantic model. They also reveal where a single shared dataset might become an operational bottleneck.

Avoid making “real-time” a blanket requirement. If month-end profitability depends on reconciled chargebacks received two days later, a low-latency pipeline can make inaccurate results appear faster. Conversely, a fraud-monitoring team may genuinely need minute-level events. A useful design makes the latency-versus-correctness tradeoff explicit and may deliver two different products: an operational approximation and a certified financial view. The diagram should indicate the contract for each output instead of presenting all arrows as equally reliable.

Understand OneLake without confusing it with a database engine

OneLake provides a unified storage foundation for Fabric, and Delta-formatted analytical tables can be accessed through several experiences. This reduces the need to maintain separate copies for every consumer. However, unified storage does not mean every engine has the same writing capabilities, permissions, or query semantics. The SQL analytics endpoint on a lakehouse is useful for querying its tables; a Fabric warehouse provides a different T-SQL-centered development experience. An architect must know which layer receives writes and which offers a read surface.

Suppose a team creates a shortcut to a curated product table rather than copying it to a second location. That may reduce duplicate storage and simplify lineage. It also adds a dependency on the source location and on permissions at the shortcut target. If the source owner changes a column, downstream reports may fail even though no local copy activity ran. Shortcuts shift part of the maintenance burden; they do not erase it. Verify both the technical path and the organizational agreement before relying on one in a production model.

Choose lakehouse, warehouse, or a combination deliberately

The decisive question is often how the team transforms and serves data. Spark notebooks, event-rich files, and exploratory data engineering align naturally with a lakehouse. T-SQL development, structured dimensional tables, and relational transformations can favor a warehouse. Fabric supports combinations, including a lakehouse for raw and validated records with a warehouse used to produce curated business tables. The detailed distinction between a data lake and a data warehouse remains useful, but neither label tells the entire story within a platform that shares OneLake storage.

Consider invoice data whose source has inconsistent currency codes and malformed timestamps. A notebook-based transformation could preserve the raw source, normalize fields, and publish validated Delta tables. A warehouse can then join those records to reference dimensions and expose stable finance facts. If the entire workload already fits clean T-SQL patterns, adding a Spark stage solely to make the design look modern may increase complexity without increasing value. The preferred architecture minimizes unnecessary translation between technologies while retaining clear quality checkpoints.

An architectural decision record should also explain what the team deliberately did not build. Perhaps a shortcut was rejected because source owners could not promise stable availability. Perhaps materializing a daily snapshot was chosen because finance needs to reproduce a closed reporting period. Or perhaps a warehouse was selected despite a lakehouse prototype being faster to create because the operational team already knows T-SQL and has a mature SQL review process. Recording alternatives makes later upgrades less arbitrary: new staff can revisit the assumption that actually drove the original choice rather than guessing from a diagram.

Architecture must also account for ownership when products change. A lakehouse table may be produced by a platform team but consumed by a shared semantic model owned elsewhere. If the producer changes a data type, schema compatibility should be checked before the model owner is asked to diagnose failed report visuals. A published data contract with a named contact and change notification path prevents the entire dependency chain from relying on informal messages. These are concrete components of the architecture, even when they cannot be represented by a storage icon.

Use medallion boundaries to distinguish trust levels

A bronze, silver, and gold arrangement is a helpful way to communicate how confidence increases across data processing. Bronze retains incoming records in a form suitable for replay and investigation. Silver resolves type mismatches, duplicate delivery, reference identifiers, and other data-quality issues. Gold expresses datasets that are ready for defined analytical consumption. This is a governance story as much as a processing story: people need to know which tables can be queried directly for official metrics and which are provisional.

The layers should contain genuine contracts. “Silver” is not trustworthy because someone named a schema that way. It becomes trustworthy when failed quality rules stop promotion, errors are observable, and transformations produce reproducible outputs. If a store number cannot be mapped, decide whether to quarantine its transactions, show them in an exception category, or temporarily omit them from a certified measure. Each choice changes a business total. Document the consequence rather than burying it inside a dataflow condition that nobody outside engineering can see.

Place the semantic model where consistency can be defended

Multiple reports should not each implement a slightly different definition of net sales. A shared semantic model can define relationships, measures, format logic, and security once, but it must rest on tables with stable keys and grain. A model built over raw order lines and a refund table without a clear matching rule will not become reliable merely because its DAX syntax is valid. Curated facts and conforming dimensions remain the foundation of the logical model.

Choose a storage mode with realistic operating conditions. Import models involve data refresh and may work well for a managed analytical snapshot. DirectQuery sends queries to an underlying source and can introduce latency dependent on that source. Direct Lake reads Delta-backed data through Fabric; behavior differs between Direct Lake on OneLake and Direct Lake on SQL endpoints, including how security and fallback are handled. Test actual query patterns, capacity behavior, identity paths, and update latency rather than declaring any mode “fastest” in every case. In a failure investigation, identify the layer actually responsible for a stale or slow result.

Design permissions across ownership boundaries

Architecture diagrams often place a padlock beside the storage layer and call security complete. In practice, a workspace role can grant broader rights than the author intended, and a shared semantic model may apply a second set of controls to report consumers. The effective identity used to query data affects what a model can reach. A shortcut’s target can have its own restrictions, and a user who can query a source directly may bypass semantic-model rules designed for report viewing. The architecture must explicitly describe those paths.

For a regional-sales scenario, assign a developer role for a controlled workspace and a reporting role for store managers, then verify effective access under both accounts. Test whether a manager can export a detail table, create a new report from the shared model, or query the underlying lakehouse. A narrow report view is not evidence that every data path is protected. Sensitivity labels and endorsement can help communicate handling expectations and trust, but neither substitutes for testing authorization. Changes to security configuration deserve the same release discipline as changes to measures.

Organize development and production as separate risk zones

Source control, workspace deployment, and impact analysis belong in the architecture from the beginning. A lakehouse definition may be tracked while its underlying table data is not; promoting an object definition does not automatically reproduce a production dataset. Teams need environment-specific connections, tested deployment pipelines, and explicit data lifecycle procedures. A change to a shared field can cascade through notebooks, warehouse views, semantic calculations, and reports, even if the initial developer never opens those consumers.

The DP-700 data-engineering path can help distinguish responsibility for ingestion infrastructure from responsibility for the analytical contract, but a functioning Fabric solution requires collaboration between those roles. A release plan should say who verifies row counts after transformation, who validates a financial measure, who approves security changes, and who can roll back a model deployment. Ownership is not administrative paperwork added after the technical design; it is one of the conditions that make the design usable over time.

Run a cost and observability review before calling the design complete. For a small proof of concept, an extra daily copy may be harmless; at enterprise scale it may create duplicate scanning, storage, and security administration. A shortcut may reduce movement but increase dependence on an external owner’s uptime. A large shared semantic model may reduce the number of competing measures yet require more structured release windows. The best option is the one whose operational costs and failure paths the team is prepared to own, not simply the one with the shortest initial setup.

Test the architecture against failure, not presentation quality

Take the retail example through three changes. First, an upstream source introduces a new currency code. Second, sales leadership requests a second reporting dimension that does not map neatly to existing orders. Third, the company adds a region whose managers must not see one another’s transactions. For each event, identify where data is validated, which contracts are affected, which objects must be modified, and how the release can be tested without exposing restricted information.

A diagram that survives those questions is more valuable than one with more platform icons. It shows why data is copied or referenced, why one engine was chosen over another, what happens when a source breaks, and how consistent business meaning reaches the consumer. Those are the architectural decisions DP-600 candidates should practice: not just where to click in Fabric, but how to build an analytics system whose results remain explainable after the people and inputs change.