Resiliência em Microsserviços

Por
Atualizado em
Publicado em
2 min. de leitura

Olá, querido(a) aluno(a)!
Neste artigo vamos tratar de um dos tópicos mais críticos em arquiteturas distribuídas: a resiliência em microsserviços. Em concursos de Tecnologia da Informação, esse tema aparece com frequência, pois representa a capacidade de um sistema de continuar funcionando de forma aceitável mesmo diante de falhas parciais, atrasos ou indisponibilidade de componentes.

Em um sistema monolítico, falhas internas podem derrubar toda a aplicação. Já em microsserviços, a expectativa é que falhas localizadas sejam absorvidas sem comprometer o todo. Isso exige a adoção de padrões de resiliência, que previnem efeitos em cascata e melhoram a experiência do usuário.

O primeiro conceito fundamental é o Circuit Breaker. Inspirado em disjuntores elétricos, ele interrompe chamadas a um serviço que já apresenta falhas recorrentes. Assim, evita sobrecarregar um microsserviço indisponível e protege os demais, devolvendo respostas alternativas (fallbacks) quando possível.

O Hystrix, desenvolvido pela Netflix, foi um dos frameworks pioneiros na implementação de circuit breakers. Embora hoje esteja em manutenção mínima, ele marcou época e ainda aparece em provas de concurso. Ele permitia configurar limites de tempo, fallback methods e dashboards para monitoramento.

Atualmente, o Resilience4j é a biblioteca mais utilizada para resiliência em Java. Leve e modular, oferece suporte não apenas a circuit breakers, mas também a limitação de taxa (rate limiting), tentativas automáticas (retries), controle de concorrência (bulkhead) e timeouts. Essa diversidade o torna mais flexível e alinhado às necessidades modernas de microsserviços.

Outro padrão essencial é o Fallback, que define uma ação alternativa quando um serviço falha. Por exemplo, se o serviço de recomendações estiver indisponível, a aplicação pode retornar uma lista padrão de itens mais vendidos em vez de exibir erro. Isso melhora a experiência do usuário e reduz impactos da falha.

O Retry é outro mecanismo importante. Ele define novas tentativas automáticas de chamada a um serviço, geralmente com políticas de backoff exponencial (aumentando o tempo entre tentativas). Isso é útil em falhas transitórias, como picos momentâneos de rede.

O padrão Bulkhead (compartimentos estanques) isola recursos entre serviços, evitando que a sobrecarga de um afete os demais. Por exemplo, um microsserviço de relatórios não deve esgotar todas as conexões de banco de dados e impedir que o microsserviço de login funcione.

Essas técnicas se somam à prática de timeouts configurados, que impedem que uma requisição fique aguardando indefinidamente. O tempo limite deve ser definido com base em SLAs e monitoramento do sistema.

Por fim, a resiliência em microsserviços não depende apenas de código. Testes de caos e ferramentas como Chaos Monkey são usadas para injetar falhas propositais em produção, validando se o sistema se comporta de forma controlada. Assim, a equipe garante que os padrões de resiliência realmente funcionam em cenários reais.

Referências essenciais

  • Richardson, C. Microservices Patterns. Manning, 2018.
  • Newman, S. Building Microservices. O’Reilly, 2021.
  • Documentação oficial Resilience4j: https://resilience4j.readme.io
  • NIST SP 800-204B: Building Secure and Reliable Microservices-based Applications.

Vamos ver como este conteúdo já foi cobrado?

1. (IMPARH – 2024 – Prefeitura de Fortaleza/CE – Analista de Regulação – Ciências da Computação)
Qual é o padrão de software usado em microsserviços que evita falhas em cascata e interrompe chamadas subsequentes para evitar sobrecarga?
a) Retry.
b) Strangler.
c) Circuit Breaker.
d) Bulkhead.

Gabarito: letra c
Comentário: O Circuit Breaker é o padrão responsável por interromper chamadas a serviços que falham repetidamente, prevenindo sobrecarga e evitando efeitos em cascata. Retry e Bulkhead também aumentam a resiliência, mas não interrompem o fluxo como o Circuit Breaker.

2. (Avança SP – 2025 – UNITAU – Programador Pleno)
Em um sistema distribuído utilizando microsserviços, qual padrão de projeto é mais adequado para lidar com falhas temporárias de comunicação entre serviços?
a) Circuit Breaker.
b) Singleton.
c) Observer.
d) Factory Method.
e) Proxy.

Gabarito: letra a
Comentário: O Circuit Breaker é utilizado para lidar com falhas temporárias de comunicação, evitando que chamadas repetidas a um serviço indisponível causem sobrecarga. Ele complementa outros mecanismos de resiliência, como retries e fallbacks.

Prof. Jósis Alves
Analista de TI no Supremo Tribunal Federal
Instagram: @josisalvesprof @aprovati

Por
Atualizado em
Publicado em
2 min. de leitura