Sistemas distribuídos falham. Disco cheio, rede lenta, serviço vizinho fora do ar. Quem projeta software há tempo sabe que a pergunta não é "se" um nó vai cair, mas "quando". Padrões de resiliência são a resposta estruturada para esse cenário: técnicas testadas em produção que impedem que uma falha pontual vire um apagão geral.
Neste guia, você encontra os 9 padrões mais usados em arquiteturas distribuídas, ordenados por relevância prática. Para cada um, um critério objetivo de aplicação e um exemplo concreto. Ao final, uma recomendação direta de qual combinação funciona para cada perfil de sistema.
1. Retry com Backoff Exponencial
O padrão mais básico e, paradoxalmente, o mais mal aplicado. Quando uma chamada falha por timeout ou erro de rede, repetir a operação parece intuitivo. O problema surge quando milhares de clientes repetem ao mesmo tempo, transformando uma falha leve em um ataque de negação de serviço.
O retry correto usa backoff exponencial: cada tentativa espera o dobro do tempo anterior, com um limite máximo e um componente de jitter. O jitter, variação aleatória no intervalo, evita o efeito thundering herd, onde todos os clientes sincronizam suas tentativas. Para operações idempotentes, como leituras ou atualizações com chave única, o retry é seguro. Para transações não idempotentes, exige cuidado com duplicidade.
2. Circuit Breaker
O circuit breaker é o fusível da arquitetura. Ele monitora chamadas a um serviço externo e, após um número definido de falhas consecutivas, abre o circuito: todas as chamadas seguintes falham rápido, sem tentar a conexão. Depois de um período de espera, o circuito entra em estado semiaberto, permitindo algumas requisições de teste.
O nome vem da analogia elétrica, e o comportamento é idêntico. Se o serviço downstream está instável, o circuit breaker evita que o cliente fique preso em timeouts longos. A biblioteca Hystrix, da Netflix, popularizou o padrão, e hoje ele está embutido em ferramentas como Resilience4j e Istio. O critério de abertura varia: 5 falhas em 10 segundos é um ponto de partida comum, mas o valor correto depende da latência do serviço e da tolerância do usuário.
3. Bulkhead (Compartimentação)
O bulkhead, ou antepara, isola falhas por partição. Em vez de um pool de conexões único para todos os consumidores, o sistema divide os recursos em compartimentos. Um serviço lento em um compartimento não esgota os recursos dos demais.
Um caso concreto: um gateway que atende duas rotas, uma para pagamentos e outra para consulta de catálogo. Sem bulkhead, uma lentidão no processador de pagamentos ocupa todas as threads, e a consulta de catálogo, que poderia responder rápido, fica bloqueada. Com dois pools separados, o catálogo continua operando. O custo é a subutilização de recursos em cenários de baixa carga, então o dimensionamento dos compartimentos precisa considerar o pico de cada tipo de chamada.
4. Fallback (Degradação Graciosa)
O fallback define um plano B para quando a operação principal falha. Em vez de retornar erro, o serviço entrega uma resposta alternativa, ainda que menos completa. O exemplo clássico é um e-commerce que, quando o serviço de recomendação está fora, exibe produtos mais vendidos no lugar de uma página de erro.
O fallback pode ser estático, com dados em cache local, ou dinâmico, chamando um serviço secundário. A decisão de usar fallback exige análise de domínio: uma operação de débito financeiro não aceita resposta de aproximação; uma busca de produtos aceita. A regra é clara: fallback para leituras e operações não críticas, nunca para transações que exigem consistência forte.
5. Cache Local e Distribuído
Cache é resiliência disfarçada. Quando o serviço de origem falha, um cache bem povoado mantém o sistema funcionando com dados eventualmente desatualizados. A estratégia mais comum em arquiteturas distribuídas é o cache local em cada instância, combinado com um cache distribuído como Redis para dados compartilhados.
A ressalva: cache introduz o problema da consistência. Um dado alterado no banco pode permanecer obsoleto no cache por minutos. Para perfis de leitura intensa, como catálogos ou configurações, o trade-off é aceitável. Para dados voláteis, como saldo de conta, o cache exige invalidação rigorosa. O padrão cache-aside, onde o sistema primeiro consulta o cache e, em caso de miss, busca na origem e atualiza o cache, é o mais adotado.
6. Timeout com Deadline Propagation
Sem timeout, uma chamada lenta segura um thread indefinidamente. Com timeout, a chamada falha após um limite definido. Parece simples, mas o diabo está na propagação: se o serviço A espera 2 segundos do serviço B, e B espera 2 segundos do serviço C, o tempo total da cadeia pode chegar a 6 segundos sem que nenhum timeout individual seja violado.
A solução é a propagação de deadline, onde o tempo restante é transmitido no cabeçalho da requisição. Cada serviço na cadeia subtrai seu próprio processamento e define um timeout menor que o deadline global. O gRPC e o OpenTelemetry suportam esse mecanismo nativamente. Sistemas sem essa propagação sofrem o efeito de acúmulo de latência, onde a resposta final chega após o cliente já ter desistido.
7. Fila com Backpressure
Quando o volume de requisições excede a capacidade de processamento, duas opções: descartar requisições ou colocá-las em uma fila. A fila suaviza picos, mas não é infinita. O backpressure é o mecanismo que informa ao produtor que o consumidor está sobrecarregado e que ele deve reduzir o ritmo.
Em sistemas com Kafka ou RabbitMQ, o backpressure aparece na configuração de prefetch e no controle de concorrência do consumidor. Sem backpressure, a fila cresce indefinidamente, a latência aumenta e, quando o consumidor finalmente processa os itens, eles já estão obsoletos. Um critério prático: se o tempo médio na fila ultrapassa o dobro do tempo de processamento, o sistema precisa de mais consumidores ou de rejeição seletiva.
8. Health Check com Readiness e Liveness
Health check é o padrão que permite ao orquestrador saber se uma instância está viva e pronta para receber tráfego. Em Kubernetes, os dois tipos de probe são distintos: liveness indica se o processo precisa ser reiniciado, readiness indica se o serviço consegue atender requisições.
A confusão entre os dois causa incidentes clássicos. Um serviço que depende de um banco externo pode estar vivo, mas não pronto. Se o readiness check falha, o orquestrador remove a instância do load balancer. Se o liveness check falha repetidamente, o pod é reiniciado. O erro comum é usar o mesmo endpoint para ambos, o que derruba instâncias saudáveis em momentos de lentidão temporária.
9. Caos Engineering e Testes de Resiliência
O nono padrão não é uma técnica de runtime, mas um processo. Caos engineering é a prática de introduzir falhas intencionais em produção para verificar se os padrões anteriores funcionam. O Chaos Monkey da Netflix, que derruba instâncias aleatoriamente, é o exemplo mais conhecido.
O objetivo não é causar estrago, mas validar hipóteses. Antes de um teste, a equipe define uma hipótese: "se o serviço de pagamento ficar indisponível por 5 minutos, o checkout deve continuar aceitando pedidos com fallback". O teste injeta a falha e mede se a hipótese se confirma. Ferramentas como Chaos Mesh e Litmus automatizam esses experimentos. A prática exige maturidade: começar em ambiente de staging e evoluir gradualmente para produção em horários de baixo tráfego.
Como escolher a combinação certa
Nenhum padrão resolve tudo sozinho. A combinação depende do perfil do sistema. Para um serviço interno com chamadas síncronas, o trio retry com backoff, circuit breaker e timeout com deadline propagation cobre a maioria dos cenários. Para APIs públicas que enfrentam picos de tráfego, adicione bulkhead para isolar clientes pesados e fila com backpressure para suavizar rajadas. Para sistemas críticos com dependência de terceiros, o fallback e o cache são obrigatórios.
O erro mais comum é implementar todos os padrões sem medir o impacto. Cada técnica adiciona latência e complexidade. Comece com retry e timeout, monitore as taxas de falha, e introduza circuit breaker apenas quando observar falhas em cascata. A resiliência é um processo incremental, não um checklist.
FAQ
O que é resiliência em sistemas distribuídos?
Resiliência é a capacidade de um sistema continuar operando, mesmo de forma degradada, quando componentes individuais falham. Inclui detecção de falhas, isolamento e recuperação automática, evitando que um problema pontual derrube todo o serviço.
Qual a diferença entre retry e circuit breaker?
Retry repete uma operação que falhou, esperando que a falha seja transitória. Circuit breaker interrompe as chamadas a um serviço que está falhando repetidamente, evitando sobrecarga. Na prática, o circuit breaker atua como um limite para o retry: após um número de tentativas, o circuito abre e o retry é suspenso.
O que é o padrão bulkhead?
Bulkhead isola recursos em pools independentes, como compartimentos de um navio. Se um serviço downstream fica lento, ele só esgota o pool reservado para ele, sem afetar as chamadas de outros consumidores. O nome vem da antepara naval que impede o alagamento total.
Como implementar circuit breaker em microsserviços?
A forma mais direta é usar uma biblioteca como Resilience4j em Java ou Polly em .NET, ou um service mesh como Istio, que configura circuit breakers no nível de rede. A configuração básica define o limite de falhas para abrir o circuito e o tempo de espera antes de testar novamente.
O que é backpressure em sistemas distribuídos?
Backpressure é o mecanismo que regula o fluxo entre produtor e consumidor quando o consumidor está sobrecarregado. Ele informa ao produtor para reduzir a taxa de envio, evitando que filas cresçam sem limite e que o sistema acumule trabalho obsoleto.
Quando usar fallback em vez de retry?
Use fallback quando existe uma alternativa aceitável para a resposta, como dados em cache ou um serviço secundário. Use retry quando a falha é provavelmente transitória e a operação é idempotente. Para operações críticas que não aceitam resposta aproximada, nenhum dos dois é adequado: o erro deve ser retornado ao cliente.