Retentativa sem teto: quando o cliente insistente vira o próprio ataque

O comportamento esperado depois de uma falha curta é uma recuperação curta: a dependência volta, as requisições voltam a ter sucesso e o tráfego retorna ao patamar anterior em alguns minutos. O que aconteceu nesse incidente foi diferente, e a diferença está na população de clientes. Durante os doze minutos de falha, cada cliente que recebeu erro não desistiu. Ele guardou o pedido e continuou tentando, e cada tentativa que falhou gerou outra. Quando a dependência voltou, o serviço não encontrou o tráfego normal esperando por ele: encontrou o tráfego normal somado a doze minutos de pedidos acumulados, todos chegando ao mesmo tempo.

Esse volume é suficiente para derrubar o serviço de novo, e aí está o mecanismo que prolonga o incidente. Com o serviço sobrecarregado, uma parte das requisições volta a falhar por tempo esgotado, e cada falha gera uma nova tentativa, que chega a um serviço ainda mais sobrecarregado. O sistema entra em um estado estável que não é o saudável: a carga que o mantém caído é produzida pela própria queda. Ele só sai desse estado quando alguém reduz a carga de fora, desligando uma rota, bloqueando um cliente ou esperando que os usuários desistam por conta própria.

Tráfego recebido pelo servico (1x = pico normal de uma terca-feira)

  9x |              ##
     |              ####
  6x |              ######   ###
     |              ######## #####  ###
  3x |              ###############  ######  ##
     |              #########################  ###
  1x |##########################################################
     +-----+--------+--------+--------+--------+--------+-------
         14:00    14:12    14:40    15:10    16:00    17:10
                 volta a    |        |        |        normal
               dependencia  +-- serviço recai por sobrecarga, repete
                                a cada onda de tentativas sincronizadas

  Queda da dependencia: 12 minutos
  Queda percebida pelo usuario: 3 horas e 10 minutos
  Participacao de repeticoes no pico: 85% das requisicoes recebidas

Visto de fora, o gráfico é idêntico ao de um ataque volumétrico, e a reação instintiva é tratá-lo como um: ativar a regra do firewall de aplicação, bloquear os endereços com mais requisições, ligar o desafio contra robôs. As três medidas pioram o problema. Os endereços com mais requisições são os clientes mais importantes, como a integração do maior parceiro, que envia muito porque vende muito. O desafio contra robôs quebra o aplicativo e as integrações, que não conseguem resolvê-lo, e transforma a falha temporária em falha permanente para quem estava apenas repetindo um pedido legítimo. O tráfego é abusivo no efeito e legítimo na origem, e a defesa precisa separar as duas coisas.

Quase nenhum cliente foi escrito para insistir para sempre. A insistência sem teto surge da combinação de decisões individualmente razoáveis, tomadas em camadas diferentes por pessoas diferentes, cada uma assumindo que as outras não repetem. Conhecer as fontes importa porque cada uma pede uma correção diferente, e várias delas estão fora do alcance do time que opera o servidor.

A segunda linha da tabela é a que produz os números mais altos, porque o efeito é multiplicativo. Se o código do aplicativo faz até três tentativas, a biblioteca HTTP embaixo dele faz outras três para cada uma, o proxy de saída da rede corporativa repete duas vezes em caso de conexão reiniciada e a mensagem chegou de uma fila que reentrega até cinco vezes, uma única ação do usuário pode produzir noventa chamadas no servidor. Nenhum dos quatro números parece exagerado isoladamente, e cada time que escolheu o seu tinha uma boa razão.

Uma acao do usuario, quatro camadas que repetem sem saber umas das outras

  fila (ate 5 entregas)
    └─ codigo do app (ate 3 tentativas)
         └─ biblioteca HTTP (ate 3 tentativas)
              └─ proxy de saida (ate 2 tentativas)
                   └─ servidor

  Pior caso = 5 x 3 x 3 x 2 = 90 chamadas para 1 acao
  Durante a queda, com todas as tentativas falhando,
  o pior caso deixa de ser teorico e vira o caso comum.

A última linha é a mais barata de corrigir e a mais comum. Um cliente que repete um erro de validação vai repeti-lo para sempre, porque o mesmo corpo sempre produz o mesmo erro. Esse tráfego não aparece apenas durante incidentes: ele existe o tempo todo, em volume baixo, e passa despercebido porque o servidor responde rápido a requisições inválidas. Em uma auditoria típica, entre dois e cinco por cento do tráfego total de uma API pública é repetição de pedidos que nunca vão ter sucesso.

O servidor não sabe, por padrão, que uma requisição é uma repetição. Para ele, a décima tentativa do mesmo pedido é idêntica a uma requisição nova, e o painel mostra apenas o total. Essa cegueira é a razão pela qual o incidente do início foi classificado como ataque: sem saber quanto do tráfego era repetição, não havia como distinguir clientes insistentes de agressores. O primeiro passo da defesa é tornar a repetição visível, e existem duas fontes de informação para isso.

• O que o cliente declara: um cabeçalho com o número da tentativa, que o seu SDK pode enviar e que você pode pedir aos parceiros que enviem. É barato e preciso, mas só existe para clientes que você controla ou convenceu.
• O que o servidor deduz: uma impressão digital da requisição, calculada a partir do cliente, da rota e da chave de idempotência ou do conteúdo do corpo, e comparada com as impressões recentes do mesmo cliente. Funciona para qualquer cliente, inclusive os que você não controla, com o custo de uma memória de curto prazo.

// Deteccao de repeticao do lado do servidor, sem depender do cliente avisar.
// A impressao digital identifica "o mesmo pedido" dentro de uma janela curta,
// e a razao de repeticao por cliente vira metrica e criterio de descarte.
import { createHash } from 'node:crypto';

const JANELA_MS = 60_000;
const impressoesRecentes = new Map(); // impressao -> { visto_em, vezes }

// O corpo cru precisa ser guardado pelo parser, por exemplo:
// app.use(express.json({ verify: (req, _res, buf) => { req.corpoBruto = buf; } }));
function impressaoDaRequisicao(req) {
  const chaveIdempotencia = req.get('idempotency-key');
  const partes = chaveIdempotencia
    ? [req.clienteId, chaveIdempotencia]
    : [
        req.clienteId,
        req.method,
        req.path,
        createHash('sha256').update(req.corpoBruto || '').digest('hex'),
      ];
  return createHash('sha256').update(partes.join('|')).digest('base64url');
}

export function detectarRepeticao(req, _res, next) {
  const agora = Date.now();
  const impressao = impressaoDaRequisicao(req);
  const anterior = impressoesRecentes.get(impressao);
  const declarada = Number(req.get('x-tentativa') || 0);

  const repetida = declarada > 0 || (anterior && agora - anterior.visto_em < JANELA_MS);
  const vezes = anterior ? anterior.vezes + 1 : 1;
  impressoesRecentes.set(impressao, { visto_em: agora, vezes });

  // Disponivel para o controle de admissao e para o log estruturado.
  req.repeticao = { repetida: Boolean(repetida), vezes, declarada };

  metricas.increment('requisicoes_total', {
    cliente: req.clienteId,
    repetida: String(Boolean(repetida)),
  });
  next();
}

// Limpeza periodica: sem ela o mapa cresce com o trafego e vira o proximo
// problema de memoria. unref() evita que o timer segure o processo aberto.
setInterval(() => {
  const limite = Date.now() - JANELA_MS;
  for (const [impressao, dado] of impressoesRecentes) {
    if (dado.visto_em < limite) impressoesRecentes.delete(impressao);
  }
}, JANELA_MS).unref();

Com a métrica rotulada por cliente e pelo indicador de repetição, a razão de repetição passa a ser o sinal mais útil do painel durante um incidente. Em operação normal ela fica abaixo de dois ou três por cento. Quando uma dependência falha, ela sobe, e o valor dela na recuperação responde a pergunta que o time de segurança não conseguiu responder: se oitenta por cento do tráfego é repetição de pedidos de clientes conhecidos, não é ataque, é demanda acumulada, e a resposta certa é organizar a fila e não bloquear a porta.

Duas ressalvas sobre a implementação. O mapa em memória funciona por instância, o que é suficiente para métrica e para descarte local, porque a razão de repetição de uma amostra é representativa do todo; um armazenamento compartilhado só se justifica se a decisão precisar ser exata entre instâncias. E a impressão pelo conteúdo do corpo pode marcar como repetidos dois pedidos legítimos idênticos, como duas consultas iguais em sequência, o que é aceitável para um sinal estatístico e é o motivo pelo qual a chave de idempotência, quando existe, tem precedência.

Um cliente só consegue parar de insistir se a resposta disser a ele que deve parar e por quanto tempo. A maioria das APIs responde a sobrecarga com um código genérico de erro de servidor, sem corpo e sem indicação de espera, e deixa para cada cliente a decisão sobre o que fazer. Com essa resposta, o comportamento de cada cliente depende inteiramente de quem o escreveu, e o pior deles define a carga que o servidor recebe. O contrato de resposta existe para reduzir essa variação.

O detalhe mais importante da tabela está na segunda linha. Se o servidor responde a todos os clientes com Retry-After de trinta segundos, ele não evitou a onda, apenas marcou a hora dela: todos os clientes que obedecem voltam juntos daqui a trinta segundos. O tempo de espera precisa ser espalhado pelo próprio servidor, porque não dá para confiar que cada cliente vai adicionar variação aleatória por conta própria. E a variação precisa ser estável por cliente, para que o mesmo cliente não receba um valor diferente a cada tentativa e acabe sempre escolhendo o menor.

// Resposta de sobrecarga que espalha as tentativas no tempo em vez de
// marcar a hora da proxima onda. O deslocamento e deterministico por cliente:
// cada um recebe sempre a mesma fatia da janela.
import { createHash } from 'node:crypto';

const ESPERA_BASE_S = 10;
const JANELA_ESPALHAMENTO_S = 50;

function deslocamentoDoCliente(clienteId) {
  const hash = createHash('sha256').update(String(clienteId)).digest();
  return hash.readUInt32BE(0) % JANELA_ESPALHAMENTO_S;
}

export function responderSobrecarga(req, res, motivo) {
  const esperaS = ESPERA_BASE_S + deslocamentoDoCliente(req.clienteId);

  res.set('Retry-After', String(esperaS));
  return res.status(503).json({
    erro: motivo,
    repetivel: true,
    tentar_apos_s: esperaS,
    // Quantas vezes vimos este mesmo pedido: ajuda quem investiga do lado do
    // cliente a perceber que o laco de repeticao dele nao tem teto.
    tentativas_observadas: req.repeticao?.vezes ?? 1,
  });
}

export function responderErroDeterministico(res, status, codigo, detalhe) {
  // Sem Retry-After de proposito: a mesma requisicao vai falhar do mesmo jeito.
  return res.status(status).json({ erro: codigo, repetivel: false, detalhe });
}

O campo repetivel no corpo resolve um problema que o código de status sozinho não resolve. Muitas bibliotecas de cliente decidem se repetem pela faixa do código, repetindo tudo que é da família cinco e nada da família quatro, o que funciona mal nas bordas: um 409 às vezes merece nova tentativa depois de consultar o estado, e um 500 causado por um corpo que quebra o servidor nunca vai ter sucesso. Um campo explícito, documentado e testado no contrato da API, transfere a decisão para quem tem a informação, que é o servidor.

O contrato de resposta reduz a insistência dos clientes que obedecem. Os que não obedecem, como a versão antiga do aplicativo que ninguém consegue atualizar, continuam chegando, e o servidor precisa de uma forma de proteger a capacidade que resta para quem ainda não foi atendido. A ideia central é que, sob sobrecarga, nem toda requisição vale o mesmo: um pedido original de um usuário que acabou de chegar tem mais valor que a décima tentativa de um pedido que já falhou nove vezes, porque a chance de a décima tentativa virar um resultado útil é menor e o custo que ela impõe ao sistema é o mesmo.

O controle de admissão abaixo implementa essa prioridade com dois limiares de concorrência. Abaixo do primeiro, tudo entra. Entre o primeiro e o segundo, só entram pedidos originais, e as repetições recebem a resposta de sobrecarga com espera espalhada. Acima do segundo, nada entra. A rejeição acontece antes de qualquer trabalho caro, o que é essencial: rejeitar depois de consultar o banco não economiza nada.

// Controle de admissao que descarta repeticoes antes de pedidos originais.
// Usa a marcacao feita por detectarRepeticao e a resposta de responderSobrecarga.
import { responderSobrecarga } from './respostas.js';

const CAPACIDADE = 200;                                // requisicoes simultaneas sustentaveis
const LIMIAR_REPETICOES = Math.floor(CAPACIDADE * 0.7); // acima disso, repeticao nao entra

let emAndamento = 0;

export function controleDeAdmissao(req, res, next) {
  const repetida = req.repeticao?.repetida === true;

  if (emAndamento >= CAPACIDADE) {
    metricas.increment('admissao_rejeitada', { motivo: 'capacidade', repetida: String(repetida) });
    return responderSobrecarga(req, res, 'capacidade_esgotada');
  }

  if (repetida && emAndamento >= LIMIAR_REPETICOES) {
    // Os 30% finais da capacidade ficam reservados para pedidos novos.
    metricas.increment('admissao_rejeitada', { motivo: 'reserva', repetida: 'true' });
    return responderSobrecarga(req, res, 'repeticao_adiada');
  }

  emAndamento += 1;
  let liberado = false;
  const liberar = () => {
    // finish e close podem disparar os dois; o contador so pode cair uma vez.
    if (liberado) return;
    liberado = true;
    emAndamento -= 1;
  };
  res.on('finish', liberar);
  res.on('close', liberar);
  next();
}

// Ordem no pipeline: identificar cliente -> detectarRepeticao -> controleDeAdmissao
// -> rotas. A deteccao precisa vir antes para a admissao conseguir priorizar.

O efeito desse mecanismo sobre a recuperação é desproporcional ao tamanho dele. No incidente do início, o serviço gastava a maior parte da capacidade processando repetições que falhavam por tempo esgotado, o que produzia mais repetições. Com a reserva, a fatia de capacidade destinada a pedidos originais continua funcionando mesmo no pico, os usuários novos são atendidos, e as repetições são empurradas para frente no tempo de forma espalhada, drenando a demanda acumulada em vez de se somarem a ela.

Esse controle convive com o limite de taxa por cliente, mas resolve outro problema. O limite de taxa protege o serviço de um cliente que consome mais do que o combinado em condições normais. O controle de admissão por tipo de requisição protege o serviço dele mesmo, no momento em que a capacidade encolheu e a demanda acumulada chegou toda de uma vez. Um cliente perfeitamente dentro da sua cota pode, junto com outros mil clientes dentro das cotas deles, produzir a onda que derruba o serviço na volta.

Tudo o que foi descrito até aqui é defesa. Quando o cliente insistente é o seu próprio aplicativo ou o SDK que você distribui para parceiros, existe uma correção mais barata e mais definitiva: dar teto à insistência na origem. O teto tem quatro componentes, e faltar qualquer um deles reabre o problema por um caminho diferente.

// Cliente com teto de insistencia: numero maximo de tentativas, prazo total,
// espera com variacao aleatoria completa, respeito ao Retry-After e parada
// imediata em erro que o servidor declarou como nao repetivel.
const PADRAO = {
  tentativasMax: 4,        // incluindo a primeira
  prazoTotalMs: 20_000,    // depois disso desiste, mesmo com tentativas sobrando
  esperaBaseMs: 500,
  esperaMaxMs: 8_000,
};

const esperar = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function lerRepetivel(resposta) {
  if (resposta.status === 429 || resposta.status === 503) return true;
  if (resposta.status < 500) return false;
  try {
    const corpo = await resposta.clone().json();
    return corpo.repetivel !== false;
  } catch {
    return true; // 5xx sem corpo legivel: tratado como transitorio
  }
}

export async function chamarComTeto(url, opcoes = {}, config = PADRAO) {
  const inicio = Date.now();

  for (let tentativa = 0; tentativa < config.tentativasMax; tentativa += 1) {
    const resposta = await fetch(url, {
      ...opcoes,
      headers: { ...opcoes.headers, 'x-tentativa': String(tentativa) },
    });

    if (resposta.ok) return resposta;
    if (!(await lerRepetivel(resposta))) return resposta; // erro deterministico: para aqui

    // Retry-After do servidor tem precedencia sobre o calculo local.
    const retryAfterS = Number(resposta.headers.get('retry-after'));
    const exponencial = Math.min(config.esperaMaxMs, config.esperaBaseMs * 2 ** tentativa);
    const espera = Number.isFinite(retryAfterS) && retryAfterS > 0
      ? retryAfterS * 1000
      : Math.random() * exponencial; // variacao completa: espalha os clientes

    const ultima = tentativa === config.tentativasMax - 1;
    if (ultima || Date.now() - inicio + espera > config.prazoTotalMs) return resposta;

    await esperar(espera);
  }
}

O prazo total é o componente mais esquecido. Um número máximo de tentativas sem prazo total permite que um servidor que manda esperar sessenta segundos a cada resposta segure o cliente por quatro minutos, com o usuário olhando para uma tela carregando. E um prazo total sem número máximo permite dezenas de tentativas rápidas quando o servidor falha instantaneamente. Os dois limites juntos definem um envelope que o usuário e o servidor conseguem prever.

1. Coloque o teto em uma única camada. Se o código do aplicativo repete, desligue a repetição da biblioteca HTTP embaixo dele, e documente no SDK distribuído a parceiros que ele já repete, para que o código deles não repita por cima.
2. Dê à fila de sincronização offline um envio espalhado na reconexão: um atraso aleatório inicial de alguns segundos a alguns minutos, proporcional ao tamanho da fila, em vez de enviar tudo no instante em que a rede volta.
3. Mantenha um interruptor remoto que reduz ou desliga as repetições do aplicativo por configuração, sem publicar versão nova, porque durante o incidente não há tempo para passar pela loja de aplicativos.
4. Registre a versão do cliente em toda requisição e defina uma versão mínima suportada, com resposta clara para versões abaixo dela, para conseguir retirar de circulação a versão com o laço sem teto.
5. Configure o consumidor de fila com número máximo de entregas e fila de mensagens mortas, e trate o aumento dela como alerta, não como depósito.
6. Escreva um teste que simula o servidor respondendo 503 com Retry-After e verifica quantas chamadas o cliente fez e quanto tempo levou, porque sem teste o teto é removido na primeira refatoração.

O terceiro item é o que decide quanto dura o próximo incidente causado pelo aplicativo. Uma versão com defeito no laço de repetição leva semanas para sair dos aparelhos, e durante esse tempo a única alavanca disponível é o que o aplicativo lê do servidor. Um aplicativo que consulta, ao iniciar e periodicamente, um documento de configuração com o número máximo de tentativas e a espera mínima pode ser corrigido em minutos, mesmo em versões antigas, desde que a leitura dessa configuração tenha existido antes do defeito.