O Que É Exponential Backoff? Explicado
O exponential backoff é uma estratégia de retry em que a espera entre tentativas cresce exponencialmente, tipicamente dobrando, para que falhas persistentes recuem rapidamente.
De todas as formas de espaçar retries, o exponential backoff é a mais amplamente usada porque se adapta à gravidade da situação. Um breve piscar se resolve após uma curta primeira espera; um problema sério rapidamente afasta os retries, poupando o sistema com falha. É a política de retry padrão em clientes bem construídos em todo lugar.
Como a matemática funciona
O atraso antes da tentativa n é um intervalo base multiplicado por um fator de crescimento elevado a uma potência, comumente base vezes dois elevado a n. Assim, as esperas podem ser 1s, 2s, 4s, 8s, 16s. Os retries iniciais são rápidos (bom para piscares) e os posteriores são bem afastados (bom para problemas sustentados), geralmente com um limite para restringir a espera máxima.
Por que exponencial, e não fixo
O backoff fixo espera a mesma quantidade toda vez, o que é lento demais para um piscar rápido ou rápido demais para uma interrupção real. O exponential backoff cobre ambos: começa responsivo e torna-se paciente, ajustando automaticamente a espera à gravidade da falha sem nenhum ajuste caso a caso.
Por que o jitter é essencial
O exponential backoff puro ainda sincroniza: se muitos clientes falham juntos, todos fazem retry em 1s, depois 2s, depois 4s, em uníssono, recriando um thundering herd. Adicionar jitter (aleatorizar cada atraso) quebra a sincronização para que os retries se espalhem. "Exponential backoff com jitter" é o padrão de nível de produção.
Onde o CI o usa
Gerenciadores de pacotes, image pulls, SDKs de nuvem e clientes de API todos usam exponential backoff para falhas de rede e de rate-limit. É a razão de um único erro transitório de registry frequentemente se recuperar sozinho: o cliente silenciosamente recua e faz retry antes que seu job sequer perceba.
O ângulo da Latchkey
Quando os runners gerenciados com autocorreção da Latchkey fazem retry de um job que falhou por um problema transitório, como um timeout de registry, um backoff sensato garante que o retry dê tempo ao upstream para se recuperar, para que um piscar isolado não faça seu build falhar sem acumular carga sobre um serviço em dificuldade.
Principais conclusões
- O exponential backoff faz o atraso de retry crescer exponencialmente (frequentemente dobrando).
- Ele é responsivo a piscares e paciente com interrupções reais.
- O jitter é essencial para evitar retries sincronizados de thundering herd.
- É a política de retry padrão em gerenciadores de pacotes e SDKs de nuvem.