Os 4 Padrões de Resiliência que você precisa conhecer!

Não existe apenas o Circuit Breaker, conheça outros padrões.

Introdução

Continuando nossa saga de artigos sobre Microserviços, especialmente falando sobre como lidar com falhas, hoje vamos falar sobre os 4 Padrões de Resiliência.

Já falamos sobre o Circuit Breaker, hoje vamos aprender os demais padrões comuns para lidar com falhas em microserviços.

Mas antes, é importante a gente conhecer o Teorema CAP, é a base principal pra gente entender os padrões.

Consistency (Consistência): Todos que leem o dado veem a mesma versão mais recente.
Availability (Disponibilidade): O sistema sempre responde a uma requisição (mesmo que não seja com o dados mais atual).
Partition Tolerance (Tolerância a Particionamento): O sistema continua funcionando mesmo que a comunicação (rede) entre dois serviços seja interrompida (um "particionamento").

O Teorema CAP diz que, em um sistema distribuído, no momento de uma falha de rede (P), você só pode garantir ou a Consistência (C) ou a Disponibilidade (A). Você NÃO pode ter os dois.

Sistemas CP (Consistência > Disponibilidade): Um banco. Se a rede entre duas agências quebra, é melhor o sistema ficar indisponível do que mostrar um saldo errado.
Sistemas AP (Disponibilidade > Consistência): Uma rede social. Se a rede falhar, é melhor te mostrar o feed com posts um pouco mais antigos (perdendo consistência) do que não te mostrar nada (perdendo disponibilidade).

Sistemas AP

Os sistemas de microserviços falham, e quando isso acontece, geralmente priorizamos a disponibilidade (sistemas AP). Para isso, existem algumas ferramentas práticas para lidar com essas falhas.
São os Padrões de Resiliência.

Padrões de Resiliência

Imagine que o seu Serviço A (de Pedidos) precisa de uma informação e vai "ligar" para o Serviço B (de Estoque) para perguntar.

Timeout (O impaciente)

É o padrão mais básico. Você define um tempo máximo que o Serviço A está disposto a esperar pela resposta do Serviço B.

Como funciona: Se o Serviço B não atender a "ligação" em 2 segundos, o Serviço A desliga o telefone e para de esperar.
Objetivo: Evitar que o Serviço A fique "preso" indefinidamente, consumindo recursos e threads, aguardando um serviço que está lento ou travado.

Retry (O Insistente)

Se a ligação para o Serviço B falhar, o Serviço A não desiste na primeira tentativa.

Como funciona: Ele espera um pouco e tenta ligar novamente, talvez mais uma ou duas vezes. Uma boa prática é usar "backoff exponencial", ou seja, esperar um pouco mais a cada nova tentativa (ex: 1s, depois 2s, depois 4s) para não sobrecarregar o Serviço B.
Objetivo: Lidar com falhas transitórias e momentâneas. Muitas vezes, pode ter sido apenas um soluço na rede ou uma sobrecarga momentânea que fez a primeira request falhar, mas a segunda funciona perfeitamente.

Circuit Breaker (O Protetor Inteligente)

Este é o mais sofisticado e um dos mais importantes da lista. Pense no disjuntor de energia da sua casa.

Como funciona: Se o Serviço A tenta ligar para o Serviço B várias vezes seguidas e todas falham rapidamente, o disjuntor "dispara" (o circuito abre).
Circuito Aberto: Pelos próximos 60 segundos, o Serviço A nem tenta mais ligar para o Serviço B. Ele falha imediatamente, economizando tempo e recursos. Isso dá um fôlego para o Serviço B se recuperar sem ser bombardeado.
Circuito Meio-Aberto: Após os 60 segundos, o disjuntor deixa uma única ligação de teste passar. Se ela funcionar, o circuito fecha e tudo volta ao normal. Se falhar, ele abre de novo.
Objetivo: Protege tanto o Serviço A (consumidor) de desperdiçar recursos em chamadas inúteis, quanto o Serviço B (fornecedor) de ser sobrecarregado enquanto está tentando se recuperar.

Tem um artigo aqui dedicado para ele, ta bem completo (com exemplos práticos em Node.js) e com perguntas ao final para testar seu entendimento.

Fallback (O Plano B)

O que o Serviço A faz quando a chamada para o Serviço B falha de vez (seja por timeout, retries esgotados ou pelo circuit breaker aberto)? Ele executa um "Plano B".

Como funciona: Em vez de retornar um erro para o usuário, o Serviço A executa uma lógica alternativa.
Exemplos de Fallback: Retornar um dado de um cache que foi salvo anteriormente, retornar um valor padrão/genérico (ex: "Não foi possível carregas as recomendações, mas veja aqui os produtos mais vendidos", ou até mesmo enfileirar a operação para ser tentada mais tarde.
Objetivo: Garante que o sistema continue oferecendo uma experiência de usuário limitada, mas funcional, em vez de simplesmente mostrar uma página de erro.

Pratique para fixar

Conclusão

Em resumo, o Timeout evita esperas longas, o Retry lida com falhas momentâneas, o Circuit Breaker protege contra falhas contínuas e o Fallback oferece uma resposta alternativa. Esses 4 padrões são a base da resiliência em microserviços.

E você, já conhecia ou já utilizou algum desses padrões? Deixa aqui nos comentários.
Muito obrigado por ter lido até aqui, grande abraço e até o próximo artigo.