# Fallback quando dependencias falham: 8 estrategias > Fallback quando dependências falham apresenta oito estratégias para manter sistemas operantes durante indisponibilidades. Cache local, respostas parciais, circuit breakers e degradação consciente estão entre as técnicas abordadas. A seleção do fallback adequado depende do tipo de falha, da criticidade do serviço e do tempo de resposta aceitável. A implementação correta reduz impacto ao usuário final e preserva a integridade dos dados durante interrupções temporárias ou permanentes de serviços externos. *Blog Sem Juízo · Destaques · 07 de setembro de 2026 · Zeca Maranhão* Dependencia caiu e seu sistema travou? Aprenda 8 estrategias de fallback para responder com graciosidade a falhas, do cache ao degradacao consciente. Quando uma dependencia externa falha, o caos tende a se espalhar: timeout em cascata, fila de requisicoes travada, usuario olhando para uma tela de carregamento infinita. A diferenca entre um sistema fragil e um resiliente nao esta em evitar falhas, mas em como ele responde a elas. Fallback e o nome dessa resposta: a arte de seguir em frente com o que voce tem, mesmo quando o que voce esperava nao chegou. Este guia apresenta 8 estrategias de fallback para quando dependencias falham, ordenadas da mais generica a mais especifica, com criterios objetivos para escolher a sua. Nenhuma estrategia elimina a necessidade de monitoramento e alertas. Fallback e um paliativo de engenharia, nao uma carta de alforria. Mas, bem aplicado, transforma uma queda total em um soluço quase imperceptivel. ## 1. Cache local com dados previamente validos A estrategia mais direta: quando a dependencia nao responde, sirva a ultima versao dos dados que voce conseguiu obter com sucesso. Um cache em memoria ou em disco, populado durante as operacoes normais, funciona como um retrato congelado do mundo. Se a API de precos cai, o e-commerce exibe os valores da ultima sincronizacao, com um aviso discreto de possivel defasagem. O criterio de validade e o ponto delicado. Dados muito dinamicos, como cotacao de acoes, exigem um TTL curto, enquanto um catalogo de produtos pode tolerar horas de defasagem. Defina o tempo de expiracao do cache com base no dano que uma informacao antiga pode causar. Um preco desatualizado gera cancelamento de pedido; um estoque desatualizado gera frustracao. Meça o risco antes de escolher o TTL. ## 2. Dados padrao ou valores de seeder Quando nao ha cache disponivel, a proxima linha de defesa e um conjunto de dados padrao, embutido no proprio codigo ou em um arquivo de configuracao. Um servico de recomendacao pode retornar uma lista de produtos mais vendidos da semana passada, em vez de um erro. Um app de clima pode mostrar a media historica da regiao, com a ressalva de que sao dados climatologicos, nao a previsao do dia. A escolha do valor padrao exige curadoria. Nao adianta colocar qualquer numero: ele precisa ser plauzivel o suficiente para nao quebrar a experiencia. Um placeholder "0" para um saldo bancario e perigoso; um "nao informado" para um campo de endereco e aceitavel. Diferencie o que e seguro padronizar do que precisa de ausencia explicita. ## 3. Degradacao graciosa de funcionalidades Nem todo recurso precisa funcionar o tempo todo. A degradacao graciosa consiste em desligar partes nao essenciais do sistema quando uma dependencia falha, mantendo o nucleo operante. Se o servico de avaliacoes de produtos esta fora, a pagina do produto continua de pe, apenas sem a secao de estrelas. O usuario perde algo, mas nao perde o site inteiro. O mapeamento de dependencias e o primeiro passo: liste cada chamada externa e classifique seu impacto. Uma falha no sistema de pagamento impede a compra, mas uma falha no sistema de recomendacao apenas empobrece a experiencia. Defina quais modulos podem ser sacrificados e quais sao inegociaveis. A AWS recomenda criar servicos que se comportem de maneira previsivel durante falhas, evitando a logica de fallback complexa. ## 4. Provedor secundario ou servico alternativo Para dependencias criticas, manter um segundo provedor configurado e uma aposta segura. Se o servico de envio de emails principal esta fora, um provedor reserva assume a fila. Se o gateway de pagamento A falha, o gateway B processa a transacao. Essa estrategia exige duplicidade de credenciais e de testes, mas oferece uma continuidade quase total. O custo de manutencao e o contra-ponto. Cada provedor extra adiciona complexidade operacional, integracao e monitoramento. A escolha entre ter um segundo provedor ou aceitar a indisponibilidade depende do custo da parada. Um sistema de reservas de voos nao pode parar; um portal de noticias pode tolerar minutos de instabilidade. ## 5. Retry com backoff exponencial e jitter Antes de desistir de uma dependencia, vale tentar novamente, mas com educacao. O retry com backoff exponencial aumenta o intervalo entre as tentativas: 1 segundo, 2, 4, 8, com um limite maximo. O jitter adiciona aleatoriedade a esse intervalo, evitando que todas as instancias do seu servico ataquem o provedor caido ao mesmo tempo, criando um efeito de rebanho. O retry nao e um fallback em si, mas o preludio dele. A combinacao classica: tente 3 vezes com backoff; se falhar, acione o fallback. A definicao do numero de tentativas e do timeout precisa considerar o tempo total que o usuario esta disposto a esperar. Uma requisicao que leva 30 segundos para falhar e pior do que uma que falha em 5 e cai no cache. ## 6. Circuit breaker para falhas rapidas O circuit breaker e um interruptor que abre quando uma dependencia falha repetidamente, impedindo novas chamadas por um periodo. Em vez de cada requisicao esperar o timeout, o sistema falha imediatamente, com uma mensagem de erro ou um fallback predefinido. Depois de um intervalo, o circuito fecha parcialmente, permitindo algumas requisicoes de teste para verificar a recuperacao. A grande vantagem e a protecao do proprio sistema. Sem um circuit breaker, uma dependencia lenta pode esgotar o pool de conexoes do seu servico, derrubando tudo. Com ele, a falha fica contida em uma regiao isolada. A configuracao do limiar de falhas e do tempo de abertura exige observacao do comportamento real da dependencia, nao um chute. ## 7. Fila de mensagens ou processamento assincrono Quando a dependencia e um servico de processamento que aceita trabalhos em lote, a fila de mensagens e o fallback ideal. Em vez de uma chamada sincrona que falha, a solicitacao entra em uma fila e e processada quando o servico volta. O usuario recebe uma confirmacao de recebimento, e o processamento acontece em segundo plano, sem bloqueio. Essa estrategia so funciona para operacoes que nao exigem resposta imediata. Um pedido pode ser processado de forma assincrona, mas uma consulta de saldo nao pode esperar minutos. Diferencie as operacoes sincronas das assincronas no design da API e aplique fila apenas onde a latencia e toleravel. ## 8. Feature flags para desligar funcionalidades em producao A feature flag e uma chave que liga ou desliga uma funcionalidade sem deploy. Quando uma dependencia falha, a flag permite desativar a integracao afetada em segundos, substituindo-a por um comportamento alternativo ou por uma mensagem de indisponibilidade. A vantagem e a velocidade de resposta: nao precisa de uma nova versao do codigo para reagir a uma queda. O gerenciamento das flags exige disciplina. Flags acumuladas viram divida tecnica, e flags mal nomeadas geram confusao. Estabeleça um processo de revisao periodica e documente cada flag com seu proposito e responsavel. Uma flag de fallback bem mantida vale mais do que um sistema complexo de roteamento automatico. ## Qual estrategia escolher? A escolha da estrategia de fallback depende do tipo de dependencia e do impacto da falha. Para leituras de dados com tolerancia a defasagem, o cache local e a resposta mais simples e eficaz. Para funcionalidades nao essenciais, a degradacao graciosa mantem o nucleo operante com baixo custo. Para operacoes criticas e sincronas, o circuit breaker combinado com um provedor secundario oferece a maior continuidade. Comece pelo mapeamento: liste suas dependencias, classifique o impacto de cada falha e defina o fallback adequado para cada nivel. Nao tente implementar tudo de uma vez. Teste uma estrategia por vez, em ambiente controlado, e meça o tempo de recuperacao e a experiencia do usuario. A resiliencia se constroi em camadas, e cada fallback bem projetado e uma camada a menos de caos. ## FAQ ### O que e fallback em sistemas de software? Fallback e uma estrategia de contingencia que assume a falha de uma dependencia e segue com uma alternativa, como um cache local, um dado padrao ou um servico secundario. Diferente de retry, que tenta recuperar a chamada original, o fallback prioriza manter o sistema funcional, mesmo com qualidade reduzida. ### Qual a diferenca entre fallback e retry? Retry tenta a mesma chamada novamente, com ou sem intervalo, esperando que a falha seja transitoria. Fallback assume que a chamada falhou e executa um plano B, como servir dados de cache ou desligar uma funcionalidade. Na pratica, retry e uma estrategia de recuperacao, enquanto fallback e uma estrategia de sobrevivencia. ### Quando usar cache como fallback? Use cache como fallback quando a leitura de dados tolera defasagem e o custo de servir uma versao antiga e menor que o custo de uma falha total. Por exemplo, um catalogo de produtos pode usar cache de horas, mas um sistema de saldo bancario nao. Defina o TTL com base no dano de uma informacao desatualizada. ### Como evitar o fallback em sistemas distribuidos? A AWS sugere criar servicos que se comportem de maneira previsivel durante falhas, evitando a logica de fallback complexa. Isso envolve design que aceite a indisponibilidade de partes do sistema, com timeouts curtos e respostas padrao. O fallback deve ser a excecao, nao a regra, e a prevencao comeca no design da arquitetura. ### O que e degradacao graciosa? Degradacao graciosa e a pratica de desligar funcionalidades nao essenciais quando uma dependencia falha, mantendo as funcoes principais operantes. Um site de e-commerce que perde o sistema de recomendacao, mas mantem o carrinho de compras, esta degradando graciosamente. O objetivo e reduzir o impacto da falha sem derrubar todo o sistema. ### Fallback substitui a necessidade de monitoramento? Nao. Fallback e uma resposta a falha, mas nao elimina a necessidade de monitorar a saude das dependencias. Sem alertas, uma queda silenciosa pode persistir por horas, com usuarios recebendo dados desatualizados sem saber. O fallback deve ser combinado com metricas de taxa de erro e alertas para acionar a equipe quando a dependencia falhar. --- Fonte (canonical): https://blogsemjuizo.com.br/destaques/fallback-quando-dependencias-falham-8-estrategias/