Resiliência de software: o que acontece com o seu processo quando um fornecedor cai?

Quase nenhum sistema moderno funciona sozinho. Uma aplicação típica de empresa depende de uma API de pagamentos, um provedor de autenticação, um serviço de mensageria ou e-mail, APIs de mapas ou de consulta de dados, modelos de IA de terceiros, uma nuvem (AWS, Google Cloud ou Azure) e, na frente de tudo, serviços de borda como o Cloudflare, por onde passa uma fatia enorme do tráfego da internet.

Cada uma dessas peças existe por um bom motivo: é mais rápido e mais barato usar quem faz bem do que construir tudo em casa. O efeito colateral é que o seu processo de negócio passa a depender de uma cadeia de fornecedores que você não controla, e as grandes quedas recentes de provedores de nuvem e do próprio Cloudflare, que tiraram do ar de bancos a redes sociais por horas, mostraram o tamanho dessa cadeia.

O mito do funcionamento perfeito

O problema raramente está em usar fornecedores externos. Está em como os processos são desenhados em torno deles.

Na maioria das empresas, o fluxo de trabalho assume o funcionamento perfeito: o pagamento sempre aprova em segundos, a consulta ao serviço externo sempre responde, o login sempre autentica, a nuvem nunca fica indisponível. As telas, as automações e até os procedimentos do time são construídos sobre essa premissa, como se cada dependência fosse imutável e imune a erro.

Enquanto tudo funciona, essa premissa é invisível. Ela só aparece no dia em que deixa de valer.

Na vida real, a corrente arrebenta no elo que você não olha

Quando uma dessas dependências falha, o processo que assumia perfeição simplesmente para. E processo parado tem preço diferente conforme a área: o e-commerce para de vender na hora de maior tráfego, a logística não emite documentos e os caminhões não saem, o atendimento fica sem acesso ao histórico do cliente, o financeiro perde janelas de liquidação e acumula multa de SLA. Em setores como saúde e mercado financeiro, a conta é ainda mais séria, envolvendo risco regulatório e, no limite, risco para pessoas.

O detalhe incômodo: na maioria desses cenários, o seu sistema está tecnicamente no ar. Foi um fornecedor que caiu. Para o cliente, a distinção não existe, quem falhou foi você.

Sistema bem projetado assume que a falha vai acontecer

Resiliência de software é isso: projetar o sistema sabendo que cada dependência externa vai, em algum momento, ficar lenta, responder errado ou sair do ar. Não é pessimismo, é estatística: com dezenas de fornecedores na cadeia, a probabilidade de todos funcionarem perfeitamente o tempo todo é praticamente zero.

Na engenharia, isso se traduz em um conjunto de práticas conhecidas: timeouts e retries com recuo progressivo, para não travar o fluxo nem bombardear um serviço que já está sofrendo; circuit breakers, que isolam a dependência doente antes que ela derrube o resto; filas, que absorvem o trabalho quando o destino está indisponível e processam depois; cache do último dado válido, que segura a operação com informação levemente defasada; idempotência, que garante que uma tentativa repetida não gere cobrança ou pedido duplicado; e o modo degradado, em que o sistema abre mão do acessório para preservar o essencial, como um checkout que desliga a recomendação de produtos mas continua vendendo.

Para as dependências realmente críticas, entra a redundância de verdade: um segundo provedor de pagamento pronto para assumir, uma rota alternativa de envio de mensagens, um procedimento manual documentado para o time seguir enquanto a tecnologia se recupera.

Nem tudo merece redundância, e é aí que entra o processo

Redundância custa dinheiro, complexidade e manutenção. Duplicar tudo é tão errado quanto não duplicar nada. A pergunta certa não é técnica, é de negócio, e nossos colegas da Dink resumiram bem no artigo que inspirou este post: se este serviço ficar seis horas fora do ar, o que o seu cliente vai vivenciar?

Responder a essa pergunta exige entender o processo como um todo, de ponta a ponta, e não sistema por sistema. É esse mapa que revela quais dependências são um incômodo tolerável e quais são uma vulnerabilidade de negócio, onde um cache resolve, onde precisa de fornecedor reserva e onde um procedimento manual bem treinado é a melhor contingência. Sem o mapa do processo, a empresa gasta redundância onde não precisa e descobre o elo fatal durante o incidente.

É o mesmo princípio que aplicamos na sustentação de sistemas críticos: conhecer a operação inteira antes de mexer na tecnologia. E é a diferença entre um sistema que funciona na demo e um que aguenta o mundo real, distância que já exploramos no mito do projeto 90% pronto.

Por onde começar

Um exercício honesto que cabe em uma tarde: liste as dez dependências externas mais importantes da sua operação, e para cada uma responda o que o cliente vivencia se ela cair por seis horas, o que o time faz nesse cenário e quanto custa cada hora parada. Se alguma resposta for “não sabemos”, esse é o lugar de começar.

Na Espresso Labs, esse mapeamento é parte do diagnóstico que fazemos para sistemas em produção, junto dos nossos colegas da Dink, software house belga acionista da Espresso, que atende operações críticas na Europa. Se a sua operação depende de sistemas que não podem parar, traga o desafio.