Difficulty: Hard | Concepts: Fabric Capacity, Capacity Units (CU), SKUs, Smoothing, Bursting, Throttling

"How would you decide how much Fabric capacity we need?" is a favorite question for architect-level and senior data engineering interviews — because it's not a lookup-table answer, it requires reasoning about workload patterns, and most candidates have never actually had to size a capacity in production.

What Is Fabric Capacity and What Are Capacity Units (CUs)?

Microsoft Fabric doesn't charge per-item — everything (Pipelines, Notebooks, Dataflows, Power BI reports, Lakehouses) runs on a shared pool of compute called a capacity, purchased as an F-SKU (F2, F4, F8, ... up to F2048). Each SKU size grants a certain number of Capacity Units (CUs) — the underlying unit of compute/memory that every operation consumes from, whether it's a Spark job, a DAX query, or a Dataflow refresh. Fabric also uses smoothing (spreading short bursts of usage over a rolling window) and allows temporary bursting above the purchased limit — but if sustained usage exceeds capacity for too long, operations get throttled (delayed or rejected) until usage falls back below the threshold. Sizing a capacity correctly means estimating peak concurrent CU consumption across every workload sharing that capacity, not just steady-state average load.

Scenario

Your organization plans to run: 15 Power BI reports with Direct Lake mode used by 200 concurrent business users, a nightly Spark Notebook processing 2TB of data, and 4 hourly Dataflow Gen2 refreshes. How do you decide between an F16, F64, or F128 capacity?

Sizing Approach

Step	What to do
1. Inventory workloads	List every item that will run on the capacity: reports, pipelines, notebooks, dataflows
2. Start a trial capacity	Use the Fabric Capacity Metrics app on a smaller SKU (e.g., F16) to observe real CU consumption
3. Identify peak overlap windows	Find times when multiple heavy jobs run simultaneously (e.g., nightly Notebook + morning report refresh)
4. Check for throttling events	The Metrics app flags "rejected" or "throttled" operations directly — the clearest sizing signal
5. Size with headroom	Pick the SKU that keeps peak utilization around 70-80%, leaving room for growth and bursts

Worked Example

Notebook nightly job: ~40% of an F64's CUs for 45 minutes
Direct Lake report queries (200 users, peak hour): ~35% of an F64's CUs
Dataflow Gen2 hourly refreshes: ~10% of an F64's CUs, spread through the day

Peak overlap (Notebook window happens to overlap a report-heavy morning):
  40% + 35% + 10% = 85% of F64 -> tight but workable
  On F32, the same workloads would be ~170% -> guaranteed throttling
  On F128, peak drops to ~42% -> comfortable headroom, but likely overpaying

Decision: F64, monitored via the Capacity Metrics app,
with a plan to scale to F128 if user count or data volume grows 25%+

Visual Representation

Fabric Capacity Metrics App | Observe: nightly Notebook spike + morning report-query spike overlap | Peak CU usage vs SKU limit: F32 -> 170% (throttling) F64 -> 85% (workable, some headroom) F128 -> 42% (safe, but likely over-provisioned) | Choose F64 now; revisit if usage trend approaches ~90% sustained

Common Mistake to Avoid

The most common mistake is sizing capacity based on average usage rather than peak overlapping usage. A workload that's only 30% utilized on average can still throttle constantly if its busiest 20 minutes coincide with another job's busiest 20 minutes — always reason about concurrent peak load, not the daily average.

Conclusion

A strong answer walks through observing real usage via the Capacity Metrics app, reasoning about overlapping peak windows rather than averages, and sizing with headroom for growth — not simply picking the biggest SKU "to be safe," which shows a lack of cost-awareness just as much as under-sizing shows a lack of performance-awareness.