UrbanPulse Data Lab
UrbanPulse · Smart City on Microsoft Fabric
Module 1 of 10
Module 1 · Foundation

Workspace Tour & Solution Architecture

This module introduces the UrbanPulse architecture, the Fabric workspace layout used throughout the lab, and the multi-tenancy patterns the design embodies. Use it as a map for the build modules that follow.

⏱ 30 minutes
🎯 Goal: understand before build
🛠 Fabric portal + slides

Scenario - UrbanPulse Analytics

Imagine you work for UrbanPulse Analytics, a software vendor that sells a real-time Smart City Operations Platform to municipalities. The City of Metropolis just signed a contract. Two operational domains, each with both live telemetry and operational reference data:

🏥 HEALTH

Northwind Health Network

Streaming: 15 active patients streaming vitals every 8–15 seconds; admit / transfer / discharge events.

Reference data: hospital roster, wards, on-shift staff in an Azure SQL database. A facility catalog Parquet with bed counts and ICU capacity per site.

🚆 TRANSIT

Metropolis Metra (3 lines)

Streaming: Red, Blue, and Green lines reporting GPS, speed, and on-time status every 2 seconds.

Reference data: route definitions and stop sequences in Cosmos DB. Region polygons (North, Loop, West, South, Airport) shared with the hospital domain so cross-domain queries can anchor on geography.

💡
The product play. Two customer domains, four very different data shapes (real-time hub events, transactional SQL, document-store JSON, columnar Parquet) - and one Fabric workspace that unifies them without ETL pipelines. UrbanPulse's value proposition isn't "we'll build you a dashboard" - it's "we'll let your operators ask questions in plain English and get answers grounded in live and historical data, no matter which system it lives in." That's the platform you're building today.

End-to-End Architecture

The diagram below traces UrbanPulse end to end. Each arrow corresponds to a module in this lab.

Architecture diagram
Figure 1.1 - UrbanPulse end-to-end architecture, with module mapping pills along the bottom.
Layer What lives here Built in SaaS pattern
Sources Operational systems - hospital + train simulators, an Azure SQL hospital roster DB, a Cosmos DB with regions and routes, and a facility catalog Parquet in OneLake. (pre-provisioned) Heterogeneous customer environments
Azure ingest Azure Event Hubs as the unified streaming front door - three hubs (medical vitals, medical movement, metro train) carrying JSON events. (pre-provisioned) Single ingest contract per tenant
Fabric platform Eventstream → Eventhouse for hot data, Lakehouse + Direct Lake for warm/historical, Real-Time Dashboard, Power BI. Modules 2–5 Per-tenant workspace, shared capacity
AI layer Fabric Data Agent grounded on Lakehouse + KQL data (Hospital core; Transit optional). Optional Foundry connected-agent orchestrator over both of them. Modules 6, 7, 8, 9 (8–9 are stretch) Domain agents = composable building blocks

The Medallion Slice You'll Build

UrbanPulse implements the standard medallion pattern (Bronze, Silver, Gold) along two parallel paths: a hot path through the Eventhouse for sub-second streaming analytics, and a warm path through the Lakehouse for batch and historical analytics.

HOT PATH · seconds BRONZE Raw Eventhouse tables SILVER KQL update policies GOLD Materialized views + Agents WARM PATH · minutes/hours BRONZE Lakehouse Files + Delta SILVER Conformed Delta tables GOLD Direct Lake semantic model Real-Time Dashboard + Data Agent Module 5 + Module 8 Power BI Report (DirectLake) Module 6
Figure 1.2 - Two parallel medallion paths in one Fabric workspace. Hot for streaming, warm for batch + analytics.

Walkthrough - Tour Your Workspace

  1. Open your pre-provisioned workspace

    From the Fabric portal, click Workspaces in the left rail. Your lab workspace is already created and bound to the shared Fabric capacity - select it.

    The workspace is empty by design. Every item you build across Modules 2-9 lands here.

  2. Take in the empty workspace canvas

    The + New item button at the top of the canvas is the entry point you'll use to create every Fabric item across the next several modules.

    📷
    SCREENSHOT NEEDED
    module-1/02-workspace-empty.png
    Empty workspace landing page with the + New item button highlighted

  3. Inspect workspace settings & capacity

    Click Workspace settings (gear icon, top-right). Confirm:

    • Workspace type: Fabric capacity (F-SKU)
    • Capacity name: fc-isvsummit-{room}

    If anything else is selected, flag it with your coach - several items in later modules require Fabric capacity (not Trial / not Pro).

  4. Inspect access (RBAC)

    Click Manage access. Your lab account is wired in as Admin. You can leave the access list as-is for the lab; in production you'd add the customer's users as Members or Contributors here.

    ⓘ
    Multi-tenant pattern: One workspace per customer tenant, with the vendor's automation principal as Admin and the customer's users as Members or Contributors. The optional Module 10 stretch shows how this scales across customer SKUs.

Multi-Tenancy Patterns (preview)

The architecture you'll build today is what we'd actually deploy for a single customer. For a real SaaS product, you'd template it. Three common Fabric multi-tenancy patterns:

Pattern How it looks Pros Cons
Workspace-per-tenant
(this lab)		 One workspace + one capacity per customer. Hard data isolation, simple billing per tenant. More items to manage; capacity not amortized.
Workspace-per-tenant, shared capacity Many workspaces all bound to one F-SKU. Cost-efficient for many small tenants. Workspaces are still RBAC-isolated. Noisy-neighbor risk; needs careful capacity sizing.
Shared workspace, row-level isolation One workspace, one Lakehouse, tenant ID column on every table + RLS. Cheapest at scale; simple operationally. Weakest isolation; one bad query = all tenants pay.

What You Just Learned

Continue to Module 2 to begin landing data into the Lakehouse.