Integrações falham de maneiras previsíveis: ficam lentas, recusam conexão, respondem parcialmente ou oscilam por alguns minutos. Sem timeout, uma chamada externa pode prender recursos internos até afetar usuários que nem dependem diretamente dela.
Retentativas ajudam, mas também podem piorar a situação. Repetir chamadas sem critério aumenta carga justamente quando o serviço está instável e pode gerar duplicidade se a operação não for idempotente.
Timeout vem primeiro
Defina quanto tempo faz sentido esperar em cada contexto. Uma busca em tela interativa geralmente precisa de limite curto. Um processamento assíncrono pode tolerar mais tempo, desde que não bloqueie o restante do sistema.
Timeouts devem considerar conexão, leitura e operação total. Se apenas um deles é configurado, ainda existe espaço para chamadas penduradas e filas internas crescendo sem visibilidade.
Retente com critério
Use poucas tentativas, espaçadas de forma progressiva, e registre o motivo de cada falha. Se a operação altera estado, envie um identificador idempotente para que o destino reconheça repetição e evite duplicar cobrança, cadastro ou notificação.
Também separe erro temporário de erro definitivo. Credencial inválida, contrato quebrado e dados malformados não melhoram com tentativa adicional. Eles precisam de correção, não de insistência.
Proteção sistêmica
Circuit breakers, filas e alertas completam o desenho quando a integração é crítica. O objetivo é conter dano: falhar rápido, preservar o fluxo principal e dar ao time informação suficiente para agir.
Timeout tambem e contrato
Uma integracao sem timeout claro transforma lentidao em espera infinita. O limite deve refletir a experiencia que o usuario ou processo aguenta, nao apenas o tempo medio da chamada externa. Se a tela pode esperar dois segundos, o timeout precisa caber nesse orcamento. Se o processamento e assíncrono, a fila pode aceitar mais tempo, mas ainda precisa de limite, monitoramento e caminho de recuperacao.
Retentativa exige ainda mais cuidado. Repetir uma chamada que cria cobranca, envia email ou altera estoque pode duplicar efeito se nao houver idempotencia. Chave de idempotencia, identificador externo e registro de tentativa reduzem esse risco. Sem isso, retry automatico pode transformar falha temporaria em inconsistencia permanente.
Evitar tempestade de retry
Quando um servico externo fica instavel, muitos clientes tentando de novo ao mesmo tempo pioram a queda. Backoff, jitter, limite de tentativas, circuit breaker e fila de reprocessamento ajudam a desacelerar a pressao. Tambem e importante registrar falhas por tipo: timeout, erro de autenticacao, limite de taxa, dado invalido e indisponibilidade pedem respostas diferentes. A confiabilidade melhora quando a falha deixa rastro suficiente para uma decisao, nao quando tudo vira uma excecao generica.
O desenho tambem deve considerar quem sofre a demora. Em uma tela interativa, talvez seja melhor avisar que o processamento continuara em segundo plano. Em uma rotina de cobranca, pode ser melhor colocar a tentativa em fila com controle de duplicidade. Em uma busca ou recomendacao, um fallback parcial pode entregar valor suficiente sem bloquear tudo. O mesmo erro tecnico pede respostas diferentes conforme o impacto no usuario e no negocio.
Na pratica, uma integracao madura deixa claro: tempo maximo de espera, quantidade de tentativas, intervalo entre tentativas, operacoes idempotentes, condicao de circuit breaker, destino de mensagens que falharam e alerta para alguem responsavel. Sem esses elementos, o sistema ate funciona nos dias bons, mas vira aposta nos dias ruins.
Evidencia para operar
Timeout e retry tambem precisam aparecer nas metricas. Sem contagem de tentativas, taxa de sucesso depois do retry e tempo total de espera, fica impossivel saber se a estrategia ajuda ou mascara problema. Um retry que recupera 2% das falhas pode valer a pena em uma rotina importante. O mesmo retry em uma tela de usuario pode apenas piorar a percepcao de lentidao.
Logs devem carregar identificador da operacao, dependencia chamada, tentativa atual, motivo da falha e decisao tomada. Isso permite separar indisponibilidade externa, erro de configuracao, bug de payload e limite de taxa. Sem essa separacao, a equipe trata sintomas diferentes como se fossem o mesmo incidente.
A revisao final e de produto: o usuario precisa esperar, tentar de novo ou receber uma alternativa? Uma mensagem honesta, uma fila visivel ou um estado parcial podem ser melhores do que esconder a falha atras de uma roda girando. Confiabilidade tambem e comunicacao clara quando a dependencia externa nao responde.
Timeout e retry so melhoram o sistema quando existe visibilidade; observabilidade para APIs pequenas complementa essa decisão com sinais para investigar falhas.
Fontes para aprofundar
As referencias abaixo ajudam a calibrar retry e circuit breaker sem criar nova fonte de instabilidade.
- Microsoft Azure Architecture: retry pattern – detalha quando repetir uma operacao faz sentido e quais limites aplicar.
- Microsoft Azure Architecture: circuit breaker pattern – explica como proteger o sistema quando uma dependencia esta falhando.
