Throttling, smoothing and bursting

Why throttling isn't a simple cap

A naive capacity would just refuse work past its CU limit, making every spike a failure. Fabric instead uses bursting and smoothing so short bursts are absorbed and only sustained overuse is penalised.

Bursting and smoothing

• Bursting — a capacity can temporarily use more compute than its base CU to finish a demanding operation quickly, rather than running it slowly within the limit.
• Smoothing — the CU cost of that burst is then spread over a following period rather than charged all at once. Interactive operations smooth over a short window; background operations (like refreshes) smooth over a much longer window (on the order of a day). The effect: capacity evaluates usage against a rolling budget, not an instantaneous one.

The mental model is a carry-forward budget: overspend now and you're paying it down over the smoothing window. Stay over budget long enough and the capacity has borrowed against future CU it doesn't have — which is when throttling begins.

The staged throttling ladder

When smoothed usage runs persistently over 100%, Fabric applies escalating protection (roughly, in order of severity):

1. Interactive delay — interactive requests are deliberately slowed (added latency). Users feel 'reports are sluggish'.
2. Interactive rejection — interactive requests are rejected outright. Users see errors opening/using reports.
3. Background rejection — background operations (scheduled refreshes) are rejected. Data goes stale.

The order matters: the system defends interactive experience first and sheds background work last, but a badly overloaded capacity eventually fails refreshes too.

Failure modes

• The afternoon slowdown. A heavy refresh or a runaway query burns the budget; hours later, interactive delay hits and users complain with no obvious cause — because the cause was earlier and smoothed forward.
• Refreshes silently rejected. Under sustained overload, background rejection kills refreshes; reports go stale (ties to the refresh concept) with no red banner.
• Undersized capacity in permanent throttle. An F-SKU too small never clears its carry-forward debt — chronic sluggishness misread as 'Power BI is slow'.
• One workload starving the rest — a data-engineering job or a bad model eats the shared CU (the monitoring concept).

What to watch (proofs)

• Throttling and overload events: the Fabric Capacity Metrics app exposes CU usage, smoothing, carry-forward, and explicit throttling/overload windows per capacity — the definitive 'were we throttled and when'.
• Top CU consumers: the metrics app's ranking of the operations/items burning the most CU — the noisy workload behind a throttle.
• Refresh failures during overload: Get-PowerBIDataset refresh history correlated with capacity overload windows — background-rejection casualties.
• Capacity headroom: Get-PowerBICapacity / admin/capacities SKU size vs the metrics app's sustained utilisation — chronic-overload evidence for resizing.