O Que É Retry com Backoff? Explicação
Retry com backoff espera um intervalo progressivamente mais longo entre as tentativas, em vez de fazer retry instantâneo, para dar ao sistema em dificuldades tempo de se recuperar.
Retries imediatos parecem eficientes, mas quando muitos clientes fazem retry ao mesmo tempo contra um serviço sobrecarregado, eles acumulam ainda mais carga exatamente quando o serviço menos pode lidar com ela. O backoff distribui as tentativas ao longo do tempo para que o sistema tenha espaço para se recuperar.
O problema dos retries imediatos
Se um upstream está falhando porque está sobrecarregado, fazer retry imediato piora a sobrecarga. Cada retry rápido adiciona carga, o serviço permanece saturado e você obtém uma falha que se auto-reforça. O backoff quebra esse ciclo introduzindo uma pausa deliberada e crescente.
Backoff fixo vs exponencial
O backoff fixo espera o mesmo intervalo a cada vez (digamos, 5 segundos). O backoff exponencial dobra a espera a cada tentativa (1s, 2s, 4s, 8s), o que recua de forma agressiva quando as falhas persistem. O exponencial é a escolha usual porque se adapta: esperas curtas para instabilidades rápidas, esperas longas quando algo está genuinamente fora do ar.
Por que o jitter importa
Se todo cliente usa o mesmo cronograma de backoff, todos fazem retry nos mesmos instantes, recriando o problema do thundering-herd um beat depois. O jitter adiciona aleatoriedade a cada atraso para que os retries se espalhem em vez de sincronizar. Backoff com jitter é o padrão robusto de referência.
Backoff em CI
Em CI, o backoff importa mais em operações de rede e de registry: instalação de pacotes, pulls de imagem e chamadas de API contra serviços com rate limit. Um retry que espera e cresce tem muito mais chance de passar contra um registry temporariamente sobrecarregado do que um que dispara três vezes em um segundo.
A perspectiva da Latchkey
Quando os managed runners com autocorreção da Latchkey fazem retry de um job que falhou em um problema transitório como um timeout de registry, eles fazem retry de forma sensata, e não instantânea, para que a recuperação não adicione carga a um upstream já em dificuldades e uma instabilidade isolada não faça seu build falhar.
Principais conclusões
- O backoff espera um intervalo crescente entre as tentativas de retry.
- Ele impede que retries rápidos piorem um sistema sobrecarregado.
- O backoff exponencial se adapta; o jitter evita retries sincronizados.
- Em CI, ele importa mais em operações de rede e de registry.