O Golpe do IOPS: 3 Sinais de que o BurstBalance está Matando seu Banco

Por Flank Manoel da Silva Especialista Sênior Full Stack | Analista de Infraestrutura e Performance

Eu gosto de sistemas previsíveis: quando o tráfego sobe, a latência sobe um pouco e a gente escala. O problema é que, em arquitetura “stateful” na nuvem, o gargalo raramente se comporta assim por causa de um vilão silencioso: o BurstBalance.

O que eu vejo em produção nos EUA (de startup SaaS em Austin a e-commerce no Midwest) é um padrão humilhante: você passa semanas afinando CPU, cache, pool de conexões… e o incidente real acontece porque o armazenamento “só ficou lento”. Sem erro claro. Sem alarme óbvio. Só uma lentidão viscosa que cola em tudo.

E, quase sempre, quando eu vou para as métricas, tem um culpado recorrente: BurstBalance.

Eu não estou falando de teoria. Estou falando daquele momento em que você roda um REINDEX (ou migração grande), o tráfego está vivo, o load balancer continua mandando requisição, e o seu nó entra numa espécie de “morte lenta” — o pior tipo de falha.

Se você só ler esta seção, leve isso:

• Quando o BurstBalance cai, o volume pode “parecer” saudável, mas seu banco vira uma âncora. A aplicação não cai; ela apodrece em latência.
• O BurstBalance não falha como CPU. CPU costuma saturar e dar sinais cedo. Armazenamento com burst esgota créditos e despenca de performance de forma desproporcional.
• A pior parte: o ALB/NLB continua enviando tráfego para o nó lento. Do lado do usuário, vira “o site tá bugado”, “checkout travou”, “login expira”.

Se você não monitora BurstBalance + Disk Queue Depth (ou equivalente), você está esperando o incidente acontecer.

Como eu “matei” o I/O em um ambiente real

O erro mais comum que eu vejo em times americanos: eles fazem load test focado em RPS e CPU. Quando olham storage, olham “Read/Write Ops” e acham que está ok. Isso não pega o colapso de BurstBalance.

O que eu fiz foi simples e cruel: Eu criei um cenário com tráfego realista (não só pico bruto). Misturei:

1. leitura de catálogo,
2. escrita de carrinho,
3. e transações curtas de checkout.

Eu forcei um trabalho “inocente” que consome I/O como uma lixa.

Exemplos que detonam BurstBalance:

• REINDEX em PostgreSQL,
• VACUUM FULL em tabela grande (dependendo do caso),
• migração que reescreve coluna,
• backfill de dados,
• rebuild de índice em MySQL/InnoDB,
• snapshots e restores em janelas apertadas.

Eu monitorei quatro coisas ao mesmo tempo:

• BurstBalance (CloudWatch),
• VolumeQueueLength / Disk Queue Depth,
• p95/p99 do banco (latência de commit),
• p95/p99 da aplicação (tempo de request).

Quando BurstBalance começa a cair, seu sistema ainda funciona. Quando BurstBalance cruza um certo ponto, a fila de disco cresce, os commits atrasam, o pool de conexões lota, e tudo vira efeito dominó.

E por que isso foge do load test padrão? Porque teste de carga clássico não simula “trabalho de manutenção + tráfego + variância de rede + ruído de vizinhança” no storage. Na nuvem, storage é rede. E a rede tem humor.

Sim: BurstBalance é, muitas vezes, o termômetro de um problema que você só enxerga quando já está doendo.

Por que isso virou urgência agora para o americano comum (mesmo sem ele saber o que é EBS)

Nos EUA, a pressão em 2025–2026 para cortar custo de cloud ficou mais agressiva. FinOps deixou de ser “time de planilha” e virou auditoria diária.

Tradução prática: muita empresa trocou “disco rápido e caro” por “disco elástico e barato”, e apostou que a elasticidade cobriria. Aí o BurstBalance vira o limite invisível.

O americano comum não fala “BurstBalance”, mas ele sente assim:

• “o app do banco travou quando eu mais precisava”
• “o checkout congelou e cobrou duas vezes”
• “o site ficou lento e eu desisti”

Quando sua plataforma depende de banco stateful e você deixa BurstBalance como nota de rodapé, você cria uma experiência inconsistente. E experiência inconsistente destrói conversão.

E tem outro detalhe cultural local: nos EUA, chargeback é fácil e o cliente não tem paciência para “we’re investigating”. A lentidão que causa duplicidade, timeout ou abandono não vira só bug — vira prejuízo.

Quem apanha mais: três perfis de empresa (e onde o BurstBalance te embosca)

Eu vou segmentar do jeito que eu realmente vejo no mercado aqui: pelo tipo de dor e pelo tipo de tráfego.

Tabela comparativa (visão de campo):

Perfil	Sintoma em produção	Por que acontece	Onde BurstBalance entra
SaaS B2B (multi-tenant)	Lentidão “intermitente” em horário comercial	Jobs de backfill + queries ad-hoc de clientes	BurstBalance cai sem ninguém notar; suporte vira proxy de observabilidade
E-commerce (picos curtos)	Checkout com timeout e “payment pending”	Promo flash + reindex/search refresh	BurstBalance despenca e o nó fica “vivo” porém inutilizável
Plataforma de dados (ETL/analytics)	Pipeline atrasa, janelas estouram	Merge/compaction + ingest	BurstBalance vira gargalo na etapa errada e arrasta tudo

Agora, o que muda por perfil:

SaaS B2B: o inimigo é o “cliente grande” que roda query pesada no pior momento

Em SaaS, o desastre típico é o cliente enterprise que roda relatório pesado às 10:30am ET. Você não vê pico de tráfego no web tier. Você vê pico de I/O no banco. O BurstBalance começa a cair devagar. Ninguém alarma. Às 11:15am, o app inteiro “parece lento”.

E aí vem a parte irritante: o time de produto acha que é “performance de API”. O time de backend mexe em índice. O time de infra olha CPU e diz “tá baixo”. Enquanto isso, BurstBalance já está condenando você.

Aqui, a solução nunca é só “otimiza query”. É:

• separar workload,
• impor limites,
• e tratar BurstBalance como budget operacional.

E-commerce: o inimigo é a combinação de manutenção “pequena” + pico “curto”

No e-commerce americano, promo é vida. O time roda: atualização de catálogo, reindex de busca, refresh de materialized view, e o tráfego sobe. O BurstBalance some em minutos. O nó não cai. O ALB continua mandando requisição.

Isso cria um fenômeno que eu odeio: metade dos usuários tem experiência boa, metade acha que você está quebrado. Você perde confiança na marca sem nem ter um “downtime” para justificar.

Dados/ETL: o inimigo é “I/O previsível” que não é previsível

Plataformas de dados costumam planejar janelas. Só que o storage com burst não respeita sua agenda. Você roda compaction, vacuum, merge, ingest. O BurstBalance vira um interruptor: quando está alto, tudo voa. Quando baixa, vira HDD velho. E o ETL é cruel: se uma etapa atrasa, todas as outras empilham.

Cenário A vs Cenário B: o mesmo banco, duas escolhas de storage, dois destinos

Cenário A: “Vamos economizar com volume burstable e compensar no app” Aqui você confia que: cache vai segurar, retry vai resolver, e auto scaling vai salvar. O que acontece na prática:

• cache ajuda leitura, não ajuda commit;
• retry aumenta carga quando o storage já está sufocando;
• scaling de web tier aumenta pressão no banco. E BurstBalance vira uma contagem regressiva.

Cenário B: “Vamos comprar previsibilidade no storage e economizar no incidente que não aconteceu” Aqui você assume que stateful precisa de previsibilidade: volumes com IOPS provisionado onde faz sentido, gp3 configurado com IOPS/throughput adequados, ou uso de serviço gerenciado (quando o tradeoff fecha). Você gasta mais na linha de storage. Mas compra duas coisas valiosas nos EUA: confiança e estabilidade.

A diferença entre A e B não é “melhor arquitetura”. É risco financeiro. Sim, eu estou falando de dinheiro: incidentes de performance custam mais do que a diferença mensal de storage na maioria dos casos que eu auditei.

Disco na nuvem é rede com orçamento (e BurstBalance é a fatura)

Eu vou ser direto: muito diagrama vende EBS como se fosse “um SSD anexado”. Na vida real, é storage em rede com limites, filas e variância. Quando você usa volumes com comportamento de burst, você está aceitando uma regra implícita:

• “Você pode ser rápido agora, desde que você seja leve depois.”

O BurstBalance é literalmente o medidor dessa barganha. E tem um detalhe perverso: quando BurstBalance acaba, o sistema não dá tela azul. Ele fica lento.

E lentidão é mais cara do que indisponibilidade em muita operação:

• porque cria dados pela metade,
• gera duplicidade,
• espalha retrabalho,
• e explode suporte.

O protocolo que eu aplico para não ser refém de BurstBalance

Eu vou te dar um playbook que eu usaria como consultor em um time nos EUA com responsabilidade de uptime e conversão.

1) Coloque BurstBalance no painel principal (e não na aba “storage”)

Você quer: BurstBalance visível para on-call, alertas que disparem antes do colapso. Regra prática que eu uso:

• alerta “amarelo” quando BurstBalance começa tendência de queda sustentada;
• alerta “vermelho” quando BurstBalance entra em zona onde sua fila de disco cresce.

2) Correlacione com fila de disco e latência de commit

BurstBalance sozinho engana. Você precisa do trio:

1. BurstBalance
2. Disk Queue Depth (VolumeQueueLength)
3. latência do banco (commit / fsync / write latency)

3) Pare de fazer manutenção pesada em horário “morno”

Horário “morno” é armadilha. Em empresa americana, meio-dia a 4pm ET parece “normal”, mas é quando suporte está ativo, clientes estão trabalhando, e vendas estão acontecendo. Se você roda REINDEX e backfill nesse horário, você está apostando que BurstBalance não vai te trair.

4) Dê ao load balancer um critério que detecte nó zumbi

Health check “200 OK” é piada para stateful. Eu já usei: endpoint que mede tempo real de query simples no banco, ou verificação de fila interna, ou latência do próprio handler. Objetivo: se o nó está lento por BurstBalance baixo, ele sai do pool.

5) Tenha um runbook específico para BurstBalance baixo (sem improviso)

Quando BurstBalance entrar em vermelho, eu quero ações padrão:

• Congelar jobs de manutenção
• Reduzir concorrência de escrita
• Drenar nó problemático
• Aplicar “circuit breaker” em endpoints não críticos
• Se for banco self-managed: avaliar failover para nó com storage saudável
• Abrir postmortem mesmo que “voltou sozinho”

6) Refaça o desenho de storage para previsibilidade (onde realmente importa)

Aqui é onde muita empresa dos EUA economiza errado. Eu não defendo gastar sem pensar. Eu defendo gastar onde evita prejuízo. Perguntas que eu faço:

• Quais tabelas são write-heavy?
• Onde está o WAL/redo log?
• Seu workload é bursty por natureza ou por falta de disciplina de jobs?
• O gargalo é IOPS, throughput, ou latência?

“Mas eu uso Kubernetes”: como o BurstBalance mata stateful em EKS sem você notar

Em EKS, eu já vi times tratando banco em StatefulSet como “só mais um pod”. E aí o storage vira armadilha dupla: o pod reinicia e você acha que “resolveu”, mas o problema era BurstBalance e fila de disco, então volta.

Três falhas típicas:

1. Autoscaling que aumenta web pods e pressiona escrita.
2. Jobs de maintenance rodando como CronJob sem janela real.
3. Observabilidade focada em CPU/memória do pod, não em BurstBalance do volume.

Se você insiste em stateful no cluster: trate o volume como componente de primeira classe; monitore BurstBalance como SLO; e tenha uma política clara de failover.

Sinais precoces que eu uso para prever o incidente (antes do p99 explodir)

Eu gosto de sinais “antes do usuário reclamar”. Checklist de precursores:

• BurstBalance em queda constante durante 10–30 minutos
• crescimento lento mas contínuo de Disk Queue Depth
• aumento de tempo de commit no banco (mesmo com CPU baixa)
• pool de conexões saturando (threads presas esperando I/O)
• aumento de timeouts e retries na borda

O impacto prático: se você age aqui, você evita o colapso. Se você espera o dashboard de p99, você entra no modo bombeiro.

O veredito de longo prazo: previsibilidade custa menos do que o mito da elasticidade

Eu vou fechar com um conselho que eu dou como mentor técnico, sem vender milagre:

• Se o seu produto depende de escrita confiável, trate storage como parte do produto. Não é infra. É UX. BurstBalance baixo vira conversão baixa.
• Elasticidade não substitui previsibilidade em stateful. Você pode escalar stateless até cansar. Se o disco fica lento, você só escala o problema.
• Se você quer economizar nos EUA, economize evitando incidente. O custo de um “site lento” em horário comercial (suporte + abandono + chargeback + reputação) costuma ser maior do que ajustar o storage para não depender de BurstBalance como loteria.
• O melhor desenho é o que te dá uma resposta rápida quando a nuvem muda de humor. Monitorar BurstBalance, reagir cedo e ter runbook reduz o tempo de sofrimento.

Entendido. Vamos elevar o tom. Esta versão da Conclusão abandona o tecnicismo passivo e foca na responsabilidade executiva e técnica, tratando o BurstBalance como o divisor de águas entre uma operação amadora e uma engenharia de classe mundial.

Conclusão:

O erro fatal da arquitetura moderna é tratar o armazenamento em nuvem como um recurso infinito e puramente elástico. Em 2026, com a pressão de FinOps de um lado e a intolerância do usuário à latência do outro, o BurstBalance deixou de ser uma métrica de infraestrutura para se tornar um KPI de sobrevivência do negócio. Ignorar o esgotamento de créditos de I/O é aceitar, conscientemente, que sua aplicação tem um prazo de validade determinado pela carga de trabalho, e não pela sua vontade.

Na prática, quando o BurstBalance entra em colapso, o que morre não é o servidor; é a confiança do usuário. Em mercados hiper-competitivos, a “lentidão viscosa” é mais destrutiva do que o downtime total. Um site fora do ar gera um alerta e uma resposta imediata. Um site “arrastado” por causa de fila de disco gera pagamentos duplicados, carrinhos abandonados e uma degradação silenciosa da marca que nenhuma campanha de marketing consegue reverter.