Sistemas distribuídos falham o tempo todo. Redes oscilam, bancos de dados atingem limites de conexão, processos morrem por exaustão de memória. A engenharia de resiliência não existe para impedir falhas, e sim para impedir que uma falha localizada derrube o sistema inteiro.

Resiliência vem do latim resilire, saltar para trás, retornar ao estado original após sofrer uma força externa. Na computação, é a capacidade de um sistema continuar operando de forma previsível quando partes da infraestrutura colapsam.

A anatomia da falha em cascata

A comunicação síncrona via HTTP entre microsserviços cria uma dependência temporal rígida. Quando o Serviço A faz uma chamada bloqueante ao Serviço B, o Serviço A aloca threads e memória enquanto aguarda resposta. Se o Serviço B fica lento ou para de responder, as threads do Serviço A ficam retidas até o timeout.

Quando todos os recursos do Serviço A se esgotam, ele também deixa de responder, repassando a inoperância aos seus consumidores. É o efeito dominó.

+-----------------+   Chamada síncrona   +-----------------+
|   Serviço A     | -------------------> |   Serviço B     |
| (API Gateway)   | <------------------- | (Processamento) |
+-----------------+   Aguardando/Timeout +-----------------+
        |                                        |
        v                                        v
(Threads esgotadas)                     (Recurso lento/fora)
        |
        v
[Colapso em cascata]

Um detalhe que costuma passar despercebido: um serviço secundário pode derrubar o ecossistema principal. Já vi, em análise de sistemas mal projetados, um componente sem qualquer relação com a jornada do cliente final, dedicado apenas a exibir documentação interna, comprometer a disponibilidade dos demais quando a resiliência era inexistente. O acoplamento não perdoa a irrelevância funcional do serviço.

Desacoplamento assíncrono via filas

A estratégia primária contra a dependência síncrona é introduzir um intermediário de mensagens. A comunicação passa a ser assíncrona: o produtor publica um evento em uma fila central e libera imediatamente seus recursos, sem aguardar o processamento.

+-----------+  Publica  +----------------+  Consome  +-----------+
| Serviço A | ---------> | Fila de Mensagens | -------> | Serviço B |
| (Produtor)| (Imediato) | (RabbitMQ/Kafka)  |          |(Consumidor)|
+-----------+            +----------------+            +-----------+

A fila funciona como buffer de absorção de choque. Se o consumidor fica indisponível, as mensagens permanecem retidas com persistência garantida. O impacto fica restrito à latência do processamento, preservando a disponibilidade do produtor e a estabilidade para o cliente final.

O padrão Circuit Breaker

Quando a integração síncrona é inevitável, entra o Circuit Breaker (disjuntor). Inspirado em dispositivos de proteção elétrica, ele monitora taxa de erros e latência das chamadas externas e corta o fluxo quando o serviço dependente está degradado.

O padrão opera como uma máquina de estados finitos:

  1. Fechado (Closed): o fluxo passa normalmente e a biblioteca monitora sucessos e falhas em uma janela de tempo.
  2. Aberto (Open): quando a taxa de falhas ultrapassa o limite configurado, o disjuntor abre. As chamadas subsequentes falham imediatamente (fail-fast), sem reter recursos.
  3. Meio-Aberto (Half-Open): após uma janela de espera, um número limitado de requisições de teste é permitido. Se passarem, o disjuntor volta a Fechado. Se falharem, volta a Aberto.
        Taxa de erro > threshold
FECHADO -------------------------> ABERTO
   ^                                 |
   |  Sucesso nos testes             | Janela expirada
   |                                 v
   +----------------------------- MEIO-ABERTO

O ganho é concreto: ao identificar que o serviço dependente está fora do ar, o consumidor interrompe o tráfego e concede tempo para a infraestrutura degradada se restabelecer, em vez de acumular chamadas condenadas.

Tolerância a falhas no ciclo de vida dos containers

A aplicação prática da resiliência aparece na gestão da infraestrutura orquestrada. Em Kubernetes, eliminar um pod deve ser um evento corriqueiro e inofensivo para a operação global.

Os mecanismos que sustentam essa estabilidade:

  • Liveness e Readiness Probes: o orquestrador direciona tráfego apenas a instâncias inicializadas e remove containers irrecuperáveis.
  • Degradação graciosa: entregar resposta parcial quando um serviço secundário está inacessível. Se o serviço de recomendações falha, o catálogo continua funcionando.
  • Estratégias de cache: camada de contingência para dados de leitura frequente, reduzindo carga sobre bancos e serviços externos.

A meta é que qualquer pod possa ser eliminado sem afetar os demais, dentro de condições controladas. Isso transforma falhas de infraestrutura de emergências operacionais em eventos estatísticos previstos, isolados e absorvidos pelo próprio design.

Conclusão

Resiliência é uma disciplina de projeto, não um remédio aplicado depois do incidente. Desacoplar por filas, proteger integrações síncronas com Circuit Breaker e projetar para que cada componente seja descartável são decisões que se tomam na arquitetura, no início. Quem trata falha como certeza projeta sistemas que sobrevivem a ela.

Sobre o autor. Robson Cassiano é engenheiro de software sênior com quase uma década de atuação em backend Java e Kotlin, com experiência em arquiteturas de microsserviços, observabilidade e sistemas distribuídos de alta disponibilidade. Publica análises técnicas a partir de experiência prática em ambientes corporativos críticos.