Quando estamos trabalhando com microsserviços ou qualquer sistema distribuído, uma coisa é certa: falhas vão acontecer.

Redes instáveis, serviços sobrecarregados ou até mesmo falhas inesperadas em um servidor…

A questão não é se vai falhar, mas quando vai falhar.

É aí que entram os patterns de resiliência, que ajudam a manter seu sistema funcionando mesmo em situações como essas.

Vamos explorar um pouco sobre dois dos mais importantes padrões: Circuit Breaker Pattern e Retry Pattern.

Circuit Breaker Pattern

Imagine que um dos seus microsserviços está tentando se comunicar com outro serviço, mas esse segundo serviço está sobrecarregado ou fora do ar.

O serviço que faz a chamada (upstream) continua enviando requisições repetidamente, sem receber resposta.

Isso gera um acúmulo de tentativas falhas e consome recursos como threads, CPU e memória no upstream, resultando em latência elevada e timeouts neste serviço.

Embora o problema original esteja no serviço de destino (downstream), o upstream também começa a sofrer com o acúmulo de tentativas, o que pode sobrecarregar todo o sistema e gerar um efeito cascata.

O serviço upstream começa a falhar, afetando outros serviços que dependem dele, potencialmente levando a uma indisponibilidade generalizada.

O Circuit Breaker Pattern entra em ação para prevenir esse cenário, evitando falhas em cascata e mantendo o sistema resiliente.

Quando uma série de falhas consecutivas é detectada, uma espécie de “disjuntor” é aberto no serviço upstream, impedindo que novas requisições sejam enviadas temporariamente ao serviço downstream.

Isso protege o serviço upstream de sobrecarga e também dá tempo para que o serviço downstream se recupere.

Sem essa pausa, o serviço downstream continuaria a ser bombardeado por requisições, agravando ainda mais o problema.

O circuito passa por três estados:

• Fechado: o sistema opera normalmente, enviando requisições.
• Aberto: após várias falhas consecutivas, o circuito “abre” e bloqueia novas requisições.
• Meio-aberto: depois de um período de tempo, o sistema tenta uma nova requisição para verificar se o serviço downstream está disponível novamente.

Retry Pattern

O Retry Pattern é exatamente o que parece: ele faz uma nova tentativa quando uma requisição falha.

Se uma requisição falha devido a um problema temporário, como uma pequena instabilidade na rede, o Retry Pattern faz com que a aplicação tente repetir a operação após um curto intervalo.

Ele é muito útil em situações em que a falha pode ser transitória, ou seja, algo que pode se resolver em questão de segundos.

Funciona assim:

Quando ocorre uma falha (exemplo: uma exceção de timeout), o sistema aguarda um intervalo de tempo (que pode ser progressivo) e tenta novamente.

Isso pode ser feito um número limitado de vezes (com contagem de tentativas) para evitar requisições infinitas.

Uma combinação bem comum é o uso do Retry Pattern junto com o Circuit Breaker Pattern. 

Primeiro, o sistema tenta algumas vezes (Retry). Se o problema persistir, o Circuit Breaker intervém para parar as tentativas e proteger o sistema.

Legal, né?

Esses são apenas dois dos padrões mais utilizados para garantir a resiliência dos seus microsserviços. Implementando esses padrões, você pode reduzir significativamente o impacto de falhas inesperadas no seu sistema.

E aí, você já implementou esses padrões nos seus microsserviços?

Na nova formação Especialista Microsserviços nós vamos abordar estes e diversos outros patterns de resiliência.

Em breve vou compartilhar mais detalhes para quem estiver na lista de espera. Faça seu cadastro agora para não perder.

Um abraço.