# Retry Backoff Exponencial ou Linear: qual usar

> Retry Backoff Exponencial ou Linear define a estratégia de espera entre tentativas de operação falha. O backoff exponencial aumenta o intervalo de forma multiplicativa, reduzindo carga no servidor e priorizando recuperação rápida, enquanto o linear cresce de forma constante, gerando latência previsível. A escolha entre custo, latência e recuperação depende do cenário: exponencial para sistemas distribuídos sob alta contenção, linear para requisitos de tempo fixo.

*PosUp · Apps e Software · 26 de agosto de 2026 · Patrícia Lemos*

Retry com backoff exponencial ou linear? A escolha muda o comportamento do sistema sob falha. Veja o que cada estratégia entrega em custo, latência e recuperação.

## O dilema: quanto esperar antes de tentar de novo?

Quando uma chamada falha, a pergunta não é se você deve tentar de novo, mas **quanto tempo esperar entre tentativas**. Retry com backoff exponencial ou linear? A resposta muda o custo da sua operação e a chance de derrubar o serviço que você tenta acessar.

**Retry com backoff exponencial** dobra o intervalo a cada tentativa (1s, 2s, 4s, 8s). **Retry com backoff linear** mantém o mesmo intervalo (2s, 2s, 2s). Ambos resolvem o mesmo problema, mas com comportamentos opostos sob carga. Nós vamos comparar pelos critérios que importam para decisão: preço de implementação, impacto no servidor, facilidade de uso e previsibilidade.

## Preço de implementação: exponencial custa mais código

Implementar backoff exponencial exige lógica extra: cálculo do intervalo, teto máximo e, idealmente, jitter (variação aleatória) para evitar que todas as requisições tentem juntas no mesmo segundo. Isso é mais código e mais teste.

Backoff linear é trivial: um sleep com valor constante. Se você tem uma fila interna ou um job que roda em horário controlado, o custo de implementar exponencial pode não se pagar. O retorno aparece quando o volume é alto e o servidor remoto já está sob estresse.

## Impacto no servidor: exponencial protege, linear pressiona

O pior cenário para um serviço sobrecarregado é receber uma rajada de tentativas no mesmo instante. Com backoff linear, se 100 clientes falham juntos, eles tentam juntos a cada 2 segundos, mantendo a pressão constante. Com exponencial, os intervalos crescem, e a carga diminui progressivamente.

Um exemplo concreto: um gateway de pagamento que fica fora do ar por 30 segundos. Com linear de 2s, você tenta 15 vezes no período. Com exponencial (1s, 2s, 4s, 8s, 16s), você tenta 4 vezes, com chance maior de acertar quando o serviço volta. Para APIs externas, exponencial é a escolha padrão.

## Facilidade de uso: linear para começar, exponencial para escalar

Se o seu sistema ainda não tem retry, comece com linear. É fácil de debugar, o comportamento é previsível e o log fica simples de ler. Exponencial exige configurar teto máximo (por exemplo, nunca esperar mais que 30s) e jitter para não sincronizar tentativas.

O jitter é o detalhe que separa um retry funcional de um retry perigoso. Sem ele, exponencial vira linear disfarçado: todos os clientes chegam ao mesmo intervalo e criam picos. A adição de ±20% aleatório no intervalo resolve isso, mas é mais uma variável para controlar.

## Previsibilidade: linear vence no SLA, exponencial vence na recuperação

Backoff linear dá tempo máximo de retry calculável: 5 tentativas com 2s = 10s no pior caso. Isso facilita definir timeout e comunicar SLA para o usuário. Exponencial tem pior caso variável, mas em compensação reduz drasticamente o número de chamadas inúteis.

Para filas internas de mensageria, linear é aceitável porque o consumidor é único e o volume é conhecido. Para integrações com terceiros, exponencial é o que impede que seu sistema seja banido por abuso.

## Tabela comparativa rápida

| Critério | Exponencial | Linear | |---|---|---| | Custo de implementação | Médio (jitter, teto) | Baixo | | Impacto no servidor | Reduz carga progressivamente | Mantém pressão constante | | Previsibilidade de tempo | Baixa | Alta | | Uso recomendado | APIs externas, nuvem | Filas internas, testes |

## Veredito: quando usar cada um

Para quem integra com **APIs externas, serviços de nuvem ou qualquer recurso compartilhado**, use **backoff exponencial com jitter e teto máximo**. É o que protege o serviço alvo e evita que seu retry vire um ataque de negação de serviço.

Para quem tem **fila interna, job agendado ou ambiente controlado**, use **backoff linear**. A simplicidade vale mais do que a otimização, e o comportamento previsível facilita o diagnóstico.

## Perguntas frequentes sobre retry backoff

### Qual a diferença entre backoff exponencial e linear?

Exponencial multiplica o intervalo a cada tentativa (1s, 2s, 4s). Linear mantém o mesmo intervalo (2s, 2s, 2s). Exponencial reduz a carga no servidor ao longo do tempo; linear mantém pressão constante.

### Por que usar jitter no retry exponencial?

Sem jitter, todos os clientes que falharam juntos tentam juntos no mesmo intervalo, criando picos de requisição. O jitter adiciona variação aleatória, distribuindo as tentativas e evitando sincronização.

### Retry linear é ruim para APIs externas?

Em geral, sim. Se a API está sobrecarregada, tentativas repetidas no mesmo intervalo mantêm a pressão e podem piorar a falha. Exponencial dá tempo para o serviço se recuperar.

### Qual o teto máximo recomendado para backoff exponencial?

Não existe valor universal. O teto deve ser definido pelo seu SLA e pelo tempo de recuperação típico do serviço. Valores comuns ficam entre 30s e 60s, mas depende do contexto.

### Posso misturar as duas estratégias?

Sim. Um padrão comum é usar exponencial até um teto e depois manter intervalo fixo. Isso combina a proteção inicial com a previsibilidade posterior, útil em filas longas.

---

Fonte (canonical): https://posup.com.br/apps-e-software/retry-backoff-exponencial-ou-linear-qual-usar/