RETRY STORMS PODEM VIRAR UM DDoS INTERNO

Em sistemas distribuídos, a tentativa automática de recuperação pode se transformar em uma fonte de pressão maior do que a falha original

Domain • Runtime & Performance Engineering

Article Code • P01A012

Reading Time • 35 min

Complexity • Intermediate

Este artigo explora como retry storms se formam em sistemas distribuídos modernos e por que tentativas automáticas de recuperação podem amplificar pressão operacional em vez de reduzi-la. O conteúdo analisa retry coupling, overload propagation, synchronized retries, downstream amplification, retry budget, backoff economics e a diferença entre recuperar falhas e multiplicar carga sobre um sistema já degradado.

Recomendado para profissionais que atuam com backend Java, sistemas distribuídos, plataformas financeiras, performance engineering, runtime engineering e arquitetura enterprise.

Opening thesis

Retry é um dos mecanismos mais intuitivos de resiliência em sistemas distribuídos. Quando algo falha ou demora demais, tentar novamente parece uma resposta razoável. Em muitos contextos, de fato é.

Falhas transitórias, perda temporária de resposta, instabilidade pontual de rede ou pequenas variações de disponibilidade podem ser absorvidas com retry, desde que a arquitetura tenha sido desenhada para isso.

O problema é que retry deixa de ser mecanismo de proteção quando a própria falha já está ocorrendo em um ambiente saturado. Nesse cenário, repetir uma chamada não significa apenas “dar outra chance ao sistema”. Significa adicionar nova pressão sobre componentes que já estão trabalhando sob atraso, contenção, backlog e degradação progressiva. A tentativa de recuperação passa a competir pelos mesmos recursos que já estavam sob estresse. O sistema então não apenas falha, ele passa a falhar com mais carga, mais concorrência e mais pressão distribuída do que antes. Esse é um dos pontos centrais deste artigo.

Em arquiteturas modernas, retry pode facilmente se tornar uma fonte de amplificação operacional. O que começou como um mecanismo de segurança pode se transformar em um multiplicador de tráfego interno, aumentando o número de requisições concorrentes sobre downstreams já degradados. Em vez de proteger o sistema, retry começa a sustentar um padrão de repetição que consome capacidade residual mais rápido do que a arquitetura consegue dissipar. Nesse estágio, o problema já não é somente a falha original. O problema passa a ser a forma como a arquitetura reage a ela.

É exatamente assim que um retry storm nasce. Não como um acidente isolado, mas como uma cascata de decisões de recuperação executadas dentro de um ambiente operacional que já perdeu margem suficiente para absorver esse comportamento de forma segura.

Retry é útil quando a pressão ainda é controlável

Em condições saudáveis, retry cumpre uma função muito importante. Ele oferece tolerância a falhas transitórias sem exigir que toda pequena instabilidade seja imediatamente tratada como erro irreversível. Em um sistema distribuído bem calibrado, algumas chamadas realmente merecem uma nova tentativa. Uma rede instável por poucos milissegundos, uma dependência momentaneamente indisponível ou uma resposta atrasada por variação temporária podem ser resolvidas com uma política de retry apropriada.

O ponto crítico é que essa utilidade depende de uma condição básica: a pressão operacional ainda precisa estar dentro de um intervalo que permita recuperação. Se o sistema já está sob saturação, a nova tentativa deixa de ajudar e passa a competir com a própria causa do problema. A arquitetura entra em uma zona em que repetir a chamada significa sustentar mais carga sobre um ambiente que já tinha dificuldades para responder à primeira solicitação.

Essa distinção é extremamente importante em sistemas financeiros, APIs de alto volume, fluxos assíncronos e arquiteturas com dependências externas lentas. Em tais ambientes, a resposta inicial pode falhar por latência ou timeout, mas a dependência ainda pode estar processando a carga. Quando o retry entra imediatamente, a nova tentativa compete com o trabalho já em andamento. Se muitas instâncias fazem o mesmo, ao mesmo tempo, a pressão se multiplica.

Retry, portanto, não é o problema por si só. Ele se torna perigoso quando a arquitetura deixa de ter margem suficiente para suportar repetição simultânea de maneira previsível.

Quando o sistema já está degradado, retry deixa de ser proteção e vira amplificação

Um sistema saudável consegue absorver novas tentativas sem entrar em colapso de coordenação. Mas, quando a arquitetura já está degradada, cada retry se comporta como uma nova unidade de pressão sobre o mesmo ponto de falha. O downstream continua lento. O pool continua ocupado. A fila continua crescendo. O runtime continua retendo estado. A nova tentativa chega e se junta ao conjunto de chamadas que já estavam disputando os mesmos recursos.

Esse comportamento produz um efeito de amplificação. A falha original não precisa ser grande. Basta que ela aconteça em um sistema com baixa margem de dissipação. A partir daí, novas tentativas entram em cascata, elevando a carga agregada justamente sobre o componente que menos tem condição de responder.

O resultado é uma espiral de degradação: mais latência causa mais timeout, mais timeout causa mais retry, mais retry adiciona mais concorrência, mais concorrência aumenta ainda mais a pressão sobre o downstream, e a arquitetura passa a operar em um regime de retroalimentação da própria instabilidade.

Esse é um dos padrões mais caros em produção porque a origem da falha pode ser relativamente pequena, mas a resposta do sistema a ela é desproporcionalmente maior. O impacto final já não depende apenas do incidente inicial. Depende também da forma como a arquitetura expandiu a pressão sobre si mesma ao tentar se recuperar.

Em outras palavras, retry deixa de ser defesa e passa a ser vetor de propagação da instabilidade.

Retries sincronizados são especialmente perigosos

Um dos elementos mais destrutivos de um retry storm é a sincronização involuntária entre múltiplos componentes tentando se recuperar ao mesmo tempo. Se uma dependência degrada e centenas de instâncias percebem a mesma falha dentro de uma janela parecida, o retry tende a acontecer de forma concentrada. Isso cria uma onda adicional de tráfego em cima do mesmo recurso já pressionado.

O problema não está apenas no volume absoluto. Está no alinhamento temporal. Quando várias tentativas chegam quase simultaneamente, a arquitetura deixa de lidar com uma falha distribuída e passa a enfrentar uma amplificação coordenada da pressão. O downstream precisa responder a um surto de carga exatamente no momento em que já estava operando com lentidão ou instabilidade. O tempo de resposta aumenta ainda mais. Novos timeouts surgem. Mais retry é disparado. E o ciclo continua.

Esse padrão é particularmente perigoso em sistemas onde o timeout é curto, o backoff é inexistente ou o jitter não foi implementado adequadamente. Nessas condições, o sistema cria uma espécie de comportamento oscilatório onde tentativas se acumulam em ondas. Cada onda chega antes que a camada degradada tenha chance real de recuperar capacidade.

Esse efeito costuma ser subestimado porque, individualmente, uma retry parece inofensiva. O problema aparece quando a arquitetura inteira adota o mesmo comportamento no mesmo intervalo de tempo. O comportamento coletivo é o que transforma uma função aparentemente segura em uma forma de sobrecarga interna.

Artefato 01 - acervo do Systems Engineering Notes.

Backoff e jitter não são detalhes, são limites de propagação

Uma estratégia de retry madura nunca deveria se limitar a “tentar de novo”. Ela precisa controlar como e quando uma nova tentativa será feita. É exatamente nesse ponto que backoff e jitter se tornam essenciais. Eles não existem para tornar a repetição mais “bonita”. Eles existem para impedir que a pressão se acumule em ondas sincronizadas sobre o mesmo ponto já degradado.

Backoff reduz a agressividade do retry ao espaçar tentativas ao longo do tempo. Isso dá à arquitetura uma chance de recuperar parte da capacidade perdida antes de receber nova carga. Jitter impede que múltiplas instâncias executem retries no mesmo instante, reduzindo o risco de alinhamento temporal e, consequentemente, de sobrecarga concentrada.

Sem esses mecanismos, a arquitetura fica vulnerável a padrões de repetição massiva. O problema então não é apenas que há retry. É que o retry é aplicado como se o ambiente ainda estivesse saudável. Quando isso acontece em escala, a consequência não é resiliência. É amplificação de pressão.

Sistemas maduros entendem esse princípio e tratam retry como parte de uma política de contenção operacional. A nova tentativa não deve ser executada apenas porque a anterior falhou. Ela deve ser executada se e somente se a arquitetura ainda possuir margem para absorver essa repetição sem comprometer a estabilidade do conjunto.

Retry budget é o que impede a arquitetura de se autoconsumir

Outro conceito frequentemente negligenciado é retry budget. Muita gente define quantas tentativas uma chamada pode fazer, mas poucos definem quanto custo total de repetição a arquitetura pode absorver sem virar um amplificador de congestionamento interno.

Esse orçamento é essencial porque retries têm custo real. Eles ocupam conexão, thread, memória, fila, tempo de scheduler e capacidade de downstream. Se o sistema permitir que esses custos se multipliquem indefinidamente em um cenário já degradado, a tentativa de recuperação passa a consumir a própria capacidade de sobrevivência da arquitetura.

Retry budget estabelece esse limite. Ele obriga o sistema a reconhecer que a repetição não é gratuita. A nova tentativa só faz sentido se houver margem operacional suficiente para absorvê-la sem piorar o estado geral. Sem esse controle, a aplicação pode continuar insistindo em chamadas que já não deveriam ser repetidas, ampliando a pressão interna até transformar uma falha localizada em um incidente distribuído muito maior.

Isso é especialmente importante em sistemas financeiros e plataformas de missão crítica, onde o custo da sobrecarga é alto e a recorrência de uma mesma operação pode produzir impactos colaterais sérios. O budget, nesse contexto, funciona como mecanismo de sobrevivência. Ele protege o sistema de uma insistência excessiva em recuperar algo que já entrou em regime de degradação profunda.

Retry também pode gerar um efeito de DDoS interno

Quando muitos componentes de uma arquitetura começam a repetir chamadas simultaneamente contra o mesmo downstream degradado, o padrão deixa de parecer apenas uma sucessão de retries. Ele começa a se comportar como uma forma de negação de serviço interna. A diferença é que a carga não vem de fora. Ela é produzida pelo próprio sistema tentando se recuperar sem coordenação suficiente.

Esse efeito é extremamente perigoso porque o tráfego adicional não é percebido imediatamente como anomalia. Em muitos casos, cada instância está apenas “fazendo o que foi programada para fazer”: tentar novamente. Mas, em nível sistêmico, o comportamento agregado se torna destrutivo. O downstream recebe mais solicitações do que consegue sustentar. A fila cresce. O tempo de resposta piora. O runtime retém mais contexto. A pressão aumenta ainda mais. E o ambiente entra em um regime de autoamplificação.

É por isso que retry storms podem ser lidos, em termos práticos, como um DDoS interno. O sistema está infligindo a si mesmo um volume de repetição que a sua própria capacidade residual não consegue absorver. A arquitetura passa a agredir o próprio ponto de falha enquanto tenta recuperá-lo.

Essa leitura é importante porque muda a natureza da resposta operacional. O problema não é apenas “o downstream está lento”. O problema também é que a arquitetura está reagindo de uma forma que piora a lentidão. Isso exige mecanismos de contenção, limitação de retries, redução de sincronização e, em muitos casos, corte explícito da pressão em circulação.

A perspectiva FSE

Failure amplification loop

Sob a perspectiva do FSE, retry storms representam um caso clássico de amplificação de falha.

O sistema não apenas reage a um incidente. Ele multiplica o custo operacional da própria reação. Em vez de dissipar a pressão, ele a reforça. Em vez de estabilizar o ambiente, ele redistribui ainda mais carga sobre o ponto já degradado, esse princípio consolida o conceito central deste artigo:

A ideia de que mecanismos de recuperação mal coordenados podem amplificar a pressão operacional mais rapidamente do que a arquitetura consegue dissipá-la.

Esse modelo reaparece continuamente em:

• Retry coupling;
• Overload propagation;
• Saturation dynamics;
• Internal pressure escalation;
• Distributed instability;
• Recovery behavior;
• Runtime stress loops.

Porque, em sistemas modernos, a tentativa de recuperação pode virar o próprio mecanismo de colapso se a pressão já estiver alta demais.

Conclusão

Retry é uma ferramenta de resiliência importante, mas não é neutra.

Em ambientes distribuídos saudáveis, ele ajuda a absorver falhas transitórias.

Em ambientes já pressionados, ele pode se transformar em uma fonte de sobrecarga interna capaz de amplificar exatamente o problema que deveria mitigar. É por isso que retry storms devem ser tratados como um risco arquitetural real. Quando múltiplas instâncias começam a repetir chamadas em sincronia sobre um downstream degradado, o sistema passa a operar como se estivesse gerando seu próprio tráfego de sobrecarga. O resultado pode ser comparável a uma negação de serviço interna: mais carga sobre o ponto falho, mais latência, mais backlog e menos capacidade de recuperação.

A engenharia madura de resiliência precisa reconhecer esse risco e limitar a forma como o sistema reage à falha. Retry deve existir junto com backoff, jitter, budget e mecanismos de contenção. Sem isso, a recuperação não estabiliza, ela amplifica.

Em última análise, a diferença entre resiliência e colapso muitas vezes está menos na existência de retry e mais em como a arquitetura impede que a própria recuperação se torne parte da pressão.