Retry não é só tentar de novo: o que todo dev deveria saber.
Quando comecei a estudar Retry, a ideia parecia bem simples:
A API falhou? Tenta de novo.
E, de certa forma, é isso mesmo.
Mas descobri que existe um detalhe importante:
Tentar novamente pode resolver uma falha, mas também pode piorar ainda mais o problema.
Quando tentar de novo realmente ajuda?
Imagine que sua aplicação precisa buscar informações em outra API.
Você faz a chamada e ela falha porque o serviço ficou indisponível por alguns segundos.
Se desistirmos logo na primeira falha, o usuário recebe um erro.
Mas talvez, se esperarmos um pouquinho e tentarmos novamente, funcione normalmente.
É justamente aí que o Retry pode ajudar:
1ª tentativa: falhou
Espera um pouco...
2ª tentativa: falhou
Espera novamente...
3ª tentativa: funcionou
Em vez de deixar uma falha momentânea interromper todo o processo, damos algumas chances para a aplicação se recuperar.
Mas não é só colocar várias tentativas
Essa foi a parte que mais me chamou atenção.
Imagine que um serviço já está sobrecarregado e começa a falhar.
Se todas as aplicações começarem a tentar novamente várias vezes e sem nenhum intervalo, aquele serviço vai receber ainda mais requisições justamente quando já está com problemas.
Ou seja, podemos piorar aquilo que estávamos tentando resolver.
Por isso, uma estratégia melhor seria:
Tentou e falhou
Espera 1 segundo
Tenta novamente
Falhou outra vez
Espera um pouco mais
Tenta novamente
E, claro, precisa existir uma hora de parar.
Retry precisa ter controle. Não adianta simplesmente tentar até funcionar.
Nem todo erro precisa de outra tentativa
Essa parece óbvia depois que entendemos, mas eu não tinha parado para pensar nisso.
Se buscamos algo que não existe e recebemos um 404, tentar mais cinco vezes provavelmente não vai fazer aquilo aparecer.
Agora, se um serviço ficou temporariamente indisponível, uma nova tentativa pode fazer sentido.
Então uma pergunta simples pode ajudar bastante antes de usar Retry:
Esse erro pode realmente se resolver sozinho daqui a alguns segundos?
Se a resposta for não, provavelmente ficar tentando novamente não vai resolver o problema.
E como isso aparece no Java?
No Spring, podemos utilizar ferramentas como o OpenFeign para nossa aplicação conversar com outras APIs.
Mas mais importante do que decorar configurações é entender o que queremos que aconteça:
Chamei outra API
Falhou
Vale tentar novamente?
Sim
Espera um pouco
Tenta novamente
Funcionou: continua
Falhou novamente: respeita o limite
Quando entendemos o comportamento que queremos, aprender a configuração fica muito mais fácil.
Em vez de decorar código, começamos a entender por que aquela configuração existe.
3 coisas que vou lembrar antes de usar Retry
1. Nem todo erro merece outra tentativa
Primeiro preciso entender por que a chamada falhou.
Se o problema não vai desaparecer sozinho, repetir a mesma chamada provavelmente não vai ajudar.
2. Não tentar várias vezes imediatamente
Se o serviço está enfrentando uma instabilidade, bombardear ele com novas chamadas pode piorar a situação.
Esperar um pouco entre as tentativas dá uma chance para o serviço se recuperar.
3. Sempre ter um limite
Retry não significa:
"Tente até funcionar."
Para mim, faz mais sentido pensar assim:
"Existe uma chance dessa falha ser temporária, então vou tentar novamente de forma controlada."
Essa diferença parece pequena, mas mudou bastante a forma como passei a enxergar esse recurso.
No fim, Retry é mais decisão do que configuração
Antes eu enxergava Retry como uma configuração para fazer a aplicação tentar novamente quando algo desse errado.
Agora vejo que a parte mais importante acontece antes de configurar qualquer coisa.
Precisamos entender:
Por que falhou?
Vale tentar novamente?
Quanto tempo devo esperar?
Quando devo parar?
Depois que essas respostas estão claras, a configuração começa a fazer muito mais sentido.
No fim, usar Retry não é simplesmente ensinar a aplicação a insistir. É ensinar a aplicação a saber quando vale a pena tentar novamente.
E você, já usou Retry em algum projeto ou também achava que era simplesmente "deu erro, tenta de novo"?
_____________________
Indicação de livro
Release It!
Autor: Michael T. Nygard
Uma boa leitura para quem quer entender melhor por que aplicações falham e como podemos desenvolver sistemas mais preparados para lidar com esses problemas.
