Quando a estrutura falha — o que realmente acontece por trás das cortiças
Você já ficou olhando para um log de erro às três da manhã, sem fazer ideia de por onde começar? Eu também. E depois de anos lidando com isso, percebi que o problema nunca é o sintoma. O problema é a pergunta certa. Quando alguém me perguntava o que ocorre quando um serviço cai no meio do deploy, eu costumava responder com checklists genéricos. Funcionava às vezes. Outras, não. A realidade é mais chata. E mais útil.
O que ocorre quando o timeout não é configurado corretamente
Em 2019, fiz o deploy de um microsserviço de pagamento que deveria chamar três APIs externas em paralelo. Nada demais. Só que esqueci de setar um timeout global. O resultado? Um dos provedores tinha latência oscilando entre 200ms e 12 segundos. Como não havia limite, cada requisição pendurada travava uma thread do worker. Em produção, isso significava 47 requisições simultâneas, todas esperando. O servidor não caía de vez. Ele simplesmente morria devagar, request por request, até o garbage collector entrar em pânico. A workaround foi simples, mas demorei duas semanas para descobrir:
- Defini um timeout de 5 segundos por chamada externa
- Adicionei retry com exponential backoff, mas só para o primeiro provedor (os outros dois são instáveis de qualquer forma)
- Criei um fallback que retorna "pendente" em vez de error, permitindo que o cliente verifique depois
Isso reduziu o tempo médio de resposta de 8.3 segundos para 1.2. Não é perfeito. Mas funciona.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Por que a teoria não explica a prática
A documentação diz que timeouts são importantes. Isso é verdade. O que a documentação não diz é que configurar um timeout de 30 segundos em uma API que responde em 200ms na maioria das vezes vai te dar uma falsa sensação de segurança. A API pode estar lenta porque está sobrecarregada, não porque você precisa de mais tempo. Setar um timeout curto (2-3 segundos) e tratar o erro como "tente novamente mais tarde" é mais realista do que esperar 30 segundos por uma resposta que provavelmente vai falhar mesmo. Outro ponto que ninguém menciona: timeouts não resolvem problemas de conexão. Se a requisição nunca sai do seu servidor, o timeout não vai disparar. Você precisa de um health check ativo, não passivo. No meu caso, adicionei um ping de 500ms a cada segundo para cada endpoint crítico. Se três pings seguidos falharem, o serviço é marcado como down automaticamente. Isso evita o problema das threads penduradas que descrevi antes.
Os limites do que dá para controlar
Não adianta enganar ninguém: existe coisa que foge do seu controle. Provedores de API mudam a infraestrutura sem aviso. Regras de firewall entram em conflito com rotas de rede que ninguém documentou. DNS resolve errado porque a TTL estava alta demais e alguém esqueceu de atualizar. Nesses casos, nenhum timeout ou retry vai salvar você. O que funciona é ter visibilidade. Monitoramento de latência por percentil (p95, não média), alerts que disparam antes do usuário perceber, e runbooks que explicam exatamente o que fazer quando X acontece. Meu runbook atual tem 47 páginas. Ninguém lê do início ao fim. Mas quando algo quebra às três da manhã, as pessoas vão direto para a seção 3.2 e resolvem em 15 minutos. Isso vale mais do que qualquer ferramenta nova.
Se você está começando agora, não tente controlar tudo. Comece com timeouts, monitoramento básico e um plano de fallback. O resto vem com o tempo. E com alguns incidentes que vão te ensinar o que realmente importa.
