Padroes Retry: 7 Estrategias para Confiabilidade

Quando uma operacao falha, a tentacao e repetir a chamada e torcer para dar certo. Funciona algumas vezes. Mas em sistemas distribuidos, retry sem estrategia transforma uma falha pontual em uma cascata de sobrecarga. Os padroes de retry existem para responder a pergunta que todo engenheiro deveria fazer antes de dar um segundo tiro: "esta falha e temporaria ou permanente?"

Retry com criterio e a diferenca entre um sistema que se recupera sozinho e um que derruba o servico inteiro. Abaixo, os 7 padroes mais usados, ordenados do mais simples ao mais sofisticado. Cada um resolve um problema especifico, e a combinacao deles costuma ser a regra em producao.

1. Retry simples (tentativa unica)

O padrao mais basico: ao receber um erro, tenta a mesma operacao uma unica vez, imediatamente. Nao ha espera, nao ha calculo. Serve para falhas transientes rapidas, como um pacote perdido na rede ou um lock que foi liberado em milissegundos. O custo e baixo, mas o ganho tambem. Se a primeira falha foi causada por sobrecarga no servidor, uma segunda chamada imediata so piora a situacao. Use apenas quando o servico de destino tem latencia baixa e a falha e claramente momentanea, como um timeout de conexao de 1 segundo em uma rede local.

Criterio: se a operacao leva menos de 100ms e a taxa de falha historica e inferior a 1%, o retry simples resolve sem adicionar complexidade.

2. Retry com contagem fixa

Em vez de uma unica repeticao, define-se um numero N de tentativas, geralmente entre 3 e 5. Cada tentativa e feita com um intervalo fixo, por exemplo, 500ms entre elas. E o padrao que a maioria das bibliotecas implementa por padrao. O ponto critico: o intervalo fixo nao considera o estado do servidor. Se o destino esta lento, tres tentativas com 500ms de espera podem acumular 1,5 segundo de bloqueio no cliente, e isso multiplicado por milhares de requisicoes vira um backlog. Funciona bem para falhas curtas e isoladas, mas nao para degradacao prolongada.

Criterio: escolha a contagem com base no SLA da operacao. Se o timeout total nao pode passar de 2 segundos, com 3 tentativas o intervalo maximo entre elas e 500ms.

3. Retry com backoff exponencial

Em vez de esperar um tempo fixo, o intervalo dobra a cada tentativa: 1s, 2s, 4s, 8s. A logica e dar tempo ao servico para se recuperar, reduzindo a pressao. E o padrao recomendado pela maioria dos guias de resiliencia, incluindo o Azure Architecture Center, que o descreve como forma de evitar que o cliente continue "martelando" um servico indisponivel. O backoff exponencial e eficaz contra falhas de sobrecarga, mas tem um efeito colateral: se o servico volta em 3 segundos, a quarta tentativa so ocorre depois de 8 segundos, desperdicando a janela de recuperacao.

Criterio: use quando a falha indica sobrecarga (erros 429, 503) e o servico tem mecanismos de recuperacao que levam alguns segundos. O multiplicador comum e 2, mas valores entre 1.5 e 3 sao aceitaveis.

4. Retry com jitter (aleatoriedade controlada)

Backoff exponencial resolve o problema de um cliente, mas nao o de muitos. Se 10 mil clientes falham ao mesmo tempo e todos esperam 1s, 2s, 4s, eles vao bater no servico juntos novamente, criando uma onda sincronizada de requisicoes. O jitter adiciona um valor aleatorio ao intervalo: em vez de 4s, espera-se entre 3.5s e 4.5s. Esse pequeno ruido quebra a sincronia e distribui a carga ao longo do tempo. Estudos de sistemas distribuidos, como o artigo "The Tail at Scale" de 2013, mostram que a variacao aleatoria reduz significativamente o tempo de resposta sob alta concorrencia. E o padrao mais subestimado: muitos times implementam backoff sem jitter e sofrem com picos periodicos.

Criterio: adote jitter sempre que o numero de clientes simultaneos for maior que 10. O intervalo final deve ser o valor do backoff mais ou menos 20%.

5. Retry com limite de tempo total (deadline)

Sem um teto, o retry pode se arrastar por minutos, segurando threads e recursos. O padrao de deadline define um tempo maximo para todas as tentativas somadas. Por exemplo, a operacao pode falhar e ser repetida, mas o conjunto todo nao pode passar de 5 segundos. Isso protege o cliente de esperas longas e evita que uma falha de um servico secundario trave o fluxo principal. Na pratica, combina-se com o backoff exponencial: o intervalo cresce, mas o contador de tempo total limita o numero real de tentativas. Se o deadline expira, a operacao falha com um erro claro, que pode ser tratado por um fallback.

Criterio: o deadline deve ser menor que o timeout da chamada original, tipicamente 50% do valor. Se a operacao original espera 10s, o retry nao pode passar de 5s.

6. Retry seletivo por tipo de erro

Nem toda falha merece retry. Erros como 400 (requisicao invalida) ou 401 (nao autenticado) sao permanentes: repetir nao vai mudar o resultado. Erros como 408 (timeout), 429 (muitas requisicoes) e 503 (indisponivel) indicam condicoes temporarias e sao candidatos a retry. O padrao seletivo define uma lista branca de erros que disparam a repeticao, ignorando os demais. Isso evita gastar recursos tentando operacoes que nunca vao funcionar, e tambem evita mascarar bugs do proprio codigo. Um erro 500 pode ser temporario ou nao, entao a decisao depende do contexto: em APIs internas, costuma ser seguro repetir; em operacoes de escrita, e preciso cautela.

Criterio: monte a lista de erros retryaveis com base no comportamento observado do servico. Se um erro 500 aparece repetidamente mesmo apos varias tentativas, ele deve sair da lista.

7. Retry com fallback e circuit breaker

O ultimo padrao nao e apenas retry, e a combinacao com um circuit breaker. Quando o numero de falhas consecutivas passa de um limite (por exemplo, 5 em 30 segundos), o circuito abre e o sistema para de tentar por um periodo, retornando um fallback imediato: um valor em cache, uma resposta padrao ou uma chamada a um servico alternativo. Isso evita que o retry continue em um servico claramente fora do ar. O circuit breaker e o padrao complementar que o retry precisa para nao virar uma arma de autodestruicao. Em vez de repetir ate o fim, o sistema reconhece o padrao de falha e muda de estrategia.

Criterio: configure o limite de falhas com base no volume normal de erros. Se a taxa de erro media e 2%, o limite de abertura deve ser acima de 5% em uma janela de 60 segundos.

Qual padrao escolher na pratica

A resposta curta: use retry com backoff exponencial e jitter para servicos externos, retry seletivo para APIs internas e circuit breaker quando o servico e critico para o fluxo principal. Para operacoes de escrita (POST, PUT, DELETE), adicione idempotencia antes de qualquer retry, porque repetir uma operacao nao idempotente pode gerar dados duplicados. O retry simples fica para casos de baixa criticidade, e o deadline e obrigatorio em qualquer cenario com latencia controlada. Nao existe um padrao unico: a combinacao de dois ou tres deles resolve a maioria dos problemas de confiabilidade sem transformar o sistema em um gerador de trafego.

FAQ

O que e um padrao de retry em sistemas distribuidos?

Um padrao de retry e uma estrategia para repetir uma operacao que falhou, com regras sobre quando, quantas vezes e com qual intervalo. O objetivo e lidar com falhas temporarias, como timeouts ou sobrecarga, sem mascarar erros permanentes. A escolha do padrao define o comportamento do sistema sob falha.

Qual a diferenca entre retry e circuit breaker?

Retry tenta novamente a mesma operacao, geralmente com espera. Circuit breaker interrompe as tentativas por um periodo quando detecta uma taxa de falha alta. O retry age sobre falhas pontuais; o circuit breaker age sobre padroes de falha. Eles sao complementares: o retry cuida do curto prazo, o circuit breaker do medio prazo.

Quando nao usar retry?

Nao use retry para erros permanentes, como 400 ou 401, nem para operacoes nao idempotentes sem controle de duplicidade. Tambem evite retry em operacoes de longa duracao que ja consumiram muitos recursos. Se a falha indica um bug no codigo, repetir so vai aumentar o log de erros.

O que e jitter em retry?

Jitter e a adicao de um valor aleatorio ao intervalo de espera entre tentativas. Ele evita que varios clientes sincronizem suas requisicoes, o que acontece com backoff exponencial puro. O resultado e uma carga mais distribuida no servico, reduzindo picos de trafego.

Retry com backoff exponencial sempre funciona?

Nao. Ele funciona bem para sobrecarga temporaria, mas pode atrasar a recuperacao se o servico volta antes do intervalo calculado. Alem disso, sem jitter, pode causar ondas sincronizadas. E preciso combinar com deadline e circuit breaker para cobrir os cenarios de falha prolongada.

Como escolher o numero de tentativas?

O numero ideal depende do tempo total que a operacao pode gastar. Com 3 tentativas e intervalo de 1s, o tempo total e cerca de 3s. Com backoff exponencial, 3 tentativas comecando em 1s somam 7s. Defina o numero com base no SLA da operacao e no impacto de uma espera longa no usuario final.