Capacity Bursting and Smoothing (Microsoft Fabric)

Bursting and smoothing are the two mechanisms Microsoft Fabric uses to let a capacity handle spikes without slowing every job to the size that was purchased. Bursting lets an operation temporarily use more compute than the capacity’s SKU provides, so it can finish faster than the purchased size alone would allow. The speed gained still depends on the job’s own limits, such as concurrency, I/O, and the source system. Smoothing then spreads the extra consumption forward across future time, so the spike is paid back gradually instead of all at once.

How smoothing accounts for usage

Fabric measures capacity in 30-second timepoints — 2,880 of them in 24 hours. Instead of charging an operation’s consumption entirely to the timepoint when it ran, smoothing distributes it over future timepoints. How far forward depends on the kind of operation:

In an invented illustration: a nightly background job on a small capacity briefly uses several times the capacity’s size. It finishes quickly thanks to bursting, and its consumption is then spread across the next 24 hours, taking a small, steady share of every timepoint until it is paid back.

What it gives, and what it defers

• It reduces the need to size for peaks. A capacity can be sized closer to average demand, because short spikes in capacity-unit consumption are absorbed. It does not make concurrency unlimited: jobs are still admitted against the resources they need, such as Spark vCores, so watch queueing and deadlines as well as smoothed usage.
• It does not create compute. Smoothed usage is borrowed from the future. The documentation describes consumption beyond what the capacity can absorb being carried forward and burned down as usage falls.
• Background work has a long tail. Because background operations are smoothed over a full day, heavy scheduled jobs occupy part of the capacity for the following 24 hours, reducing headroom for interactive users the next morning.
• The limit is still there. When accumulated future usage grows too large, the capacity is throttled in stages, and throttling applies to every workspace on that capacity.

The operational habit that follows is to judge throttling risk from smoothed utilization over the day rather than from instantaneous peaks, to judge concurrency and deadlines from the resources jobs actually need, their queues, and their delays, and to schedule heavy background work with its 24-hour footprint in mind. How this interacts with capacity units and workspace placement is worked through in Microsoft Fabric Architecture: OneLake, Capacity, and the Move from Synapse.

References

• Microsoft Learn, Understand capacity throttling and smoothing
• Microsoft Learn, Concurrency limits and queueing in Apache Spark for Fabric
• Microsoft Learn, On-demand billing for Apache Spark in Microsoft Fabric