# O que é throttling no Microsoft Fabric

> Smoothing, bursting, carry forward e os três estágios de throttling no Microsoft Fabric, com a tabela de limites e o playbook das próximas 24 horas.

Página original: https://fabricmetrics.com.br/throttling-microsoft-fabric.html

Você não é throttled pelo que está rodando agora. Você é throttled pela dívida de CU que acumulou nas últimas 24 horas — e é por isso que a capacidade trava numa terça de manhã sem nada de anormal na tela.

## 1. Throttling não é lentidão — é cobrança

Throttling é o mecanismo que a capacidade usa para te obrigar a pagar a conta de CU que você já gastou. Quando o consumo projetado da sua capacidade passa do que a SKU entrega, o Fabric não desliga nada: ele começa a atrasar e depois a rejeitar requisições até que o excedente seja quitado.

Essa distinção é a coisa mais importante do artigo. Um relatório lento pode ser DAX ruim, modelo mal desenhado, DirectQuery mal pensado. Throttling é diferente: **todos** os relatórios da capacidade ficam lentos ao mesmo tempo, incluindo os que sempre foram rápidos. Se apenas um relatório está ruim, não é throttling. Se a capacidade inteira está ruim ao mesmo tempo, provavelmente é.

Abra dois relatórios de workspaces diferentes na mesma capacidade. Se os dois demoram de forma parecida e o Capacity Metrics mostra *Add %* acima de 100 no timepoint, você está em throttling — pare de otimizar DAX e vá para a seção 5.

## 2. Smoothing: por que o consumo de agora não é o consumo de agora

O Fabric não cobra picos instantâneos. Ele distribui o consumo de cada operação ao longo do tempo — smoothing — e essa distribuição depende do tipo de operação:

- **Interativas** (abrir relatório, filtrar visual, consulta DAX vinda do usuário): suavizadas ao longo de **5 minutos**.
- **Background** (refresh de semantic model, Dataflow Gen2, pipeline, notebook, job Spark): suavizadas ao longo de **24 horas**.

A consequência prática é brutal: o refresh gigante das 2h da manhã não aparece no gráfico como um pico às 2h. Ele aparece como um platô que se arrasta pelas 24 horas seguintes — inclusive às 9h04, quando os 300 usuários chegam. O throttling da manhã foi criado de madrugada.

## 3. Bursting e a dívida de CU

Bursting é o oposto do smoothing: a capacidade permite que uma operação consuma, por instantes, mais CU do que a SKU nominal oferece. Uma F8 pode entregar muito mais que 8 CU para um refresh terminar rápido. O tempo de execução cai — o custo, não. O excedente vira *carry forward*: uma dívida que a capacidade vai amortizar (burndown) nos timepoints seguintes.

Enquanto a soma de dívida projetada cabe em menos de 10 minutos de capacidade futura, nada acontece. É exatamente para isso que o bursting existe. Acima disso, começa a escada.

## 4. Os três estágios do throttling

A escada é definida pelo **consumo futuro** — quanto tempo de capacidade sua dívida já reservou adiante:

| Consumo futuro acumulado | Estágio | O que o Fabric faz | O que o usuário sente |
| --- | --- | --- | --- |
| Até 10 min | Bursting protegido | Absorve o pico, sem penalidade | Nada |
| 10 min a 60 min | Interactive Delay | Adiciona ~20 s a cada requisição interativa | “O Power BI está lentíssimo hoje” |
| 60 min a 24 h | Interactive Rejection | Rejeita requisições interativas; jobs background seguem | Erro ao abrir relatório; refresh ainda roda |
| Acima de 24 h | Background Rejection | Rejeita tudo, inclusive refresh e pipelines | Plataforma parada |

Opinião: o estágio mais perigoso é o primeiro. Interactive Delay não gera ticket, gera desconfiança. As pessoas param de usar o relatório e ninguém abre incidente.

Um detalhe que quase ninguém explica: os percentuais de throttling do Capacity Metrics são razões, não “gravidade”. Um Interactive Delay de 250% significa que o Fabric está tentando encaixar 25 minutos de consumo nos próximos 10 minutos. Um Background Rejection de 250% significa 2,5 vezes o orçamento diário da SKU — nesse ponto, a conta leva cerca de 36 horas para voltar a 100%.

## 5. Como confirmar throttling no Capacity Metrics

O Microsoft Fabric Capacity Metrics App responde a essa pergunta em quatro passos. Faça sempre nesta ordem:

- **System overview / Compute:** encontre o timepoint em que o CU% passou de 100. Anote o horário exato.
- **Aba de throttling:** confirme qual estágio estava ativo naquele intervalo (delay, rejeição interativa, rejeição background).
- **Overages / carry forward:** leia *Add %* (dívida adicionada), *Burndown %* (dívida paga) e *Cumulative %*. Se o cumulativo cresce por horas, o problema é estrutural, não um pico.
- **Timepoint detail:** clique no timepoint e ordene as operações por CU(s). Aqui aparece o culpado — quase sempre uma operação background que começou horas antes.

Se você precisa dos dados fora do app — para um painel próprio ou um alerta — a lista de capacidades e seu estado vêm da API do Fabric:

O Capacity Metrics guarda um histórico curto (dias, não meses) e é um relatório de análise, não de alerta. Para comparar o mês passado com este, ou para ser avisado antes do usuário reclamar, você precisa persistir esses dados em outro lugar.

## 6. As cinco causas que respondem por quase todo throttling que já vimos

- **Refresh full de modelo grande no horário errado.** Modelo import de dezenas de GB recarregado inteiro toda madrugada. Resolve-se com refresh incremental, não com SKU maior.
- **Dataflow Gen2 com staging ligado sem necessidade.** Cada staging escreve e lê de novo. É a fonte de CU invisível mais comum que encontramos.
- **Dev, teste e produção na mesma capacidade.** Um notebook experimental de um analista derruba o relatório do diretor. Separar capacidades é governança, não luxo.
- **DirectQuery/DirectLake em relatório de alto tráfego sem agregação.** Cada filtro do usuário é uma consulta no engine. Multiplique por 200 pessoas.
- **Jobs Spark concorrendo com a janela de refresh.** Dois consumidores pesados na mesma hora somam dívida que nenhum dos dois criaria sozinho.

## 7. Playbook das próximas 24 horas

Em ordem de retorno sobre esforço:

- Mover as operações background pesadas para fora da janela em que o consumo suavizado encosta no pico de uso interativo.
- Ligar refresh incremental nos dois ou três modelos que dominam a lista de CU(s).
- Desligar staging nos Dataflows Gen2 que não precisam dele.
- Ativar surge protection para impedir que jobs background estourem a capacidade e derrubem o interativo.
- Só então avaliar SKU maior — com o número na mão, não com a sensação.

## 8. O que não fazer

- **Pausar a capacidade para “zerar” a dívida.** Pausar liquida o carry forward imediatamente — e cobra. É uma decisão financeira, não um reset.
- **Escalar por pânico.** Dobrar a SKU sem corrigir a causa dobra o custo e adia o mesmo problema por alguns meses.
- **Culpar o autor do relatório antes de abrir o timepoint.** Em nove de dez casos, o relatório era a vítima.

## Perguntas frequentes

#### Interactive Rejection para meus refreshes agendados?

Não. Nesse estágio as operações background continuam rodando; só o interativo é rejeitado. Refresh só para no Background Rejection.

#### Quanto tempo o throttling dura?

Até a dívida ser amortizada. Se o cumulativo está caindo, é questão de horas. Se está estável ou subindo, você tem um problema estrutural que não passa sozinho.

#### Existe autoscale como no Premium P?

Nas SKUs F o modelo é outro: bursting e smoothing absorvem picos, e surge protection limita o background. Escala é operação manual (ou automatizada por você via API).

#### Uma F2 aguenta produção?

Aguenta cenários pequenos e bem comportados: modelo enxuto, poucos usuários simultâneos, refresh incremental. Não aguenta um lakehouse com jobs Spark e relatório corporativo ao mesmo tempo.

#### Throttling aparece em algum log?

O sintoma aparece como erro/latência nas requisições e o estado aparece no Capacity Metrics. Não existe um “evento de throttling” bonitinho para alertar — daí a necessidade de monitoramento próprio.

## Conheça o FabricBoard.

Histórico de CU além dos dias do Capacity Metrics, consumo por item e workspace, e alerta quando a dívida projetada cruza o primeiro limite — antes do usuário sentir os 20 segundos.

## Continue por aqui

A ordem de leitura das abas e as perguntas que o app responde bem.

Sete mudanças em ordem de retorno. Nenhuma delas é trocar de SKU.

Onde cada SKU quebra: usuários, tamanho de modelo, janela de refresh.

### Gostou deste artigo?

Uma análise dessas a cada duas semanas, no seu e-mail.

Conteúdo técnico sobre Microsoft Fabric e Power BI para quem opera essas plataformas todo dia. **Artigos novos toda semana.**

Criado e mantido pela **PRS Tecnologia** para contribuir com a comunidade técnica de dados. Site independente, **sem vínculo com a Microsoft** e não oficial: não representa posições da empresa. Microsoft, Microsoft Fabric e Power BI são marcas de seus respectivos proprietários. · © 2026 · fabricmetrics.com.br