DEV Community: Leticia Reis

Resiliência por Experimentação: Aplicação do ChaosEngineeringMasterDeck na Validação de uma Arquitetura de Microsserviços em Nuvem

Leticia Reis — Thu, 15 Oct 2026 12:21:25 +0000

Resumo. Sistemas distribuídos em nuvem estão sujeitos a falhas parciais que dificilmente são reproduzidas por testes funcionais convencionais. Neste artigo, apresento o Chaos Engineering como disciplina experimental voltada à verificação empírica da resiliência e descrevo o ChaosEngineeringMasterDeck, framework que minha equipe utiliza para estruturar experimentos de caos em cartas padronizadas, compostas por hipótese, variável injetada, métricas de controle, Blast Radius e condição de aborto. Como estudo de caso, relato a aplicação da carta REDE-07, que injeta latência na comunicação entre dois microsserviços Spring Boot executados no Amazon EKS. A primeira execução refutou nossa hipótese de resiliência e evidenciou o esgotamento do pool de threads causado pela ausência de limite de tempo nas chamadas remotas. Após adotarmos de forma combinada os padrões Time Limiter, Bulkhead, Circuit Breaker e Fallback, a segunda execução confirmou a hipótese. Concluo que a prática converte suposições sobre resiliência em evidências mensuráveis e fortalece a responsabilidade compartilhada característica da cultura DevOps.

Palavras-chave: Chaos Engineering; resiliência; sistemas distribuídos; microsserviços; observabilidade; DevOps.

1. Introdução

Atuo como engenheiro de software em uma equipe responsável por uma plataforma de comércio eletrônico baseada em microsserviços. Ao longo da migração dessa plataforma para a nuvem, percebi que a mesma arquitetura que nos trouxe escalabilidade e autonomia também aumentou de forma expressiva a complexidade operacional do sistema. Em uma arquitetura distribuída, cada chamada de rede representa um ponto potencial de falha, e a interação entre componentes produz comportamentos emergentes que não se manifestam em testes isolados. Falhas parciais, como degradação de latência, perda de uma zona de disponibilidade ou indisponibilidade temporária de um banco de dados, tendem a se propagar em cascata quando os mecanismos de proteção não foram adequadamente configurados.

Foi nesse contexto que minha equipe passou a adotar o Chaos Engineering, definido como a disciplina de realizar experimentos sobre um sistema com o objetivo de construir confiança em sua capacidade de suportar condições turbulentas em produção (BASIRI et al., 2016). A prática foi sistematizada pela Netflix durante a migração de sua infraestrutura para a Amazon Web Services, quando a empresa desenvolveu o Chaos Monkey, ferramenta que encerra instâncias aleatoriamente em produção para forçar o projeto de serviços tolerantes à perda de nós (BASIRI et al., 2016).

1.1 Justificativa: por que provocar falhas intencionalmente

O argumento que me convenceu a defender essa prática internamente é simples: falhas em sistemas distribuídos são inevitáveis. Quando aceito essa premissa, a pergunta relevante deixa de ser se o sistema falhará e passa a ser como ele se comportará quando falhar. Ao provocarmos falhas em condições controladas, com a equipe disponível, monitoramento ativo e plano de reversão definido, conseguimos descobrir fragilidades a um custo significativamente menor do que o de um incidente não planejado.

Os testes automatizados que já mantínhamos verificam se o sistema produz o resultado esperado sob condições conhecidas. O Chaos Engineering, por sua vez, investiga o comportamento do sistema sob condições adversas realistas, frequentemente associadas a configurações de infraestrutura, volume de tráfego e interações entre serviços que existem apenas em produção.

1.2 Mudança de paradigma

Adotar a prática exigiu de mim e da minha equipe uma mudança na forma de conceber a confiabilidade, que sintetizo no Quadro 1.

Quadro 1 – Comparação entre a abordagem tradicional e a abordagem do Chaos Engineering

Dimensão	Abordagem tradicional	Abordagem do Chaos Engineering
Objetivo	Evitar a ocorrência de falhas	Garantir a continuidade do serviço apesar das falhas
Fonte de confiança	Testes funcionais aprovados	Falhas reais suportadas sob observação
Natureza dos incidentes	Eventos inesperados	Hipóteses previamente testadas
Resiliência	Presumida a partir do projeto	Verificada empiricamente

Fonte: elaborado pelo autor.

1.3 Princípios fundamentais

Para orientar nossos experimentos, adotei como referência os Princípios de Chaos Engineering (PRINCIPLES OF CHAOS ENGINEERING, 2019), que estabelecem cinco diretrizes:

Formular uma hipótese em torno do estado estável (steady state), definido por métricas observáveis de negócio e de sistema, e não pela simples disponibilidade dos servidores.
Variar eventos do mundo real, injetando falhas que efetivamente ocorrem em produção, como latência, perda de nós e esgotamento de recursos.
Executar experimentos em produção ou no ambiente que mais se aproxime dela.
Automatizar os experimentos para que sejam executados continuamente.
Minimizar o *Blast Radius*, isto é, limitar o escopo do impacto potencial e ampliá-lo apenas à medida que a confiança no sistema aumenta.

Nas seções seguintes, descrevo como operacionalizamos esses princípios por meio do ChaosEngineeringMasterDeck e relato um estudo de caso de sua aplicação.

2. O ChaosEngineeringMasterDeck

2.1 Definição

O ChaosEngineeringMasterDeck é o framework que minha equipe desenvolveu para padronizar e priorizar experimentos de caos. Cada experimento é representado por uma carta, que possui uma versão impressa, utilizada em sessões presenciais de simulação que chamamos de GameDays, e uma versão em arquivo YAML versionado no repositório do projeto. Essa dupla representação nos permite conduzir o mesmo experimento manualmente, para fins de aprendizado coletivo, ou de forma automatizada, como etapa recorrente do pipeline de entrega.

Concebemos o framework para resolver três limitações que eu havia observado em nossa prática anterior:

Ausência de padronização: cada engenheiro descrevia experimentos de uma forma, o que impedia a comparação de resultados.
Ausência de salvaguardas: iniciávamos experimentos sem condições de interrupção previamente definidas.
Baixo engajamento: a prática era percebida pelo time como atividade adicional e desvinculada do desenvolvimento. O formato de baralho introduziu um componente de gamificação que, na minha experiência, favoreceu a participação conjunta das equipes de desenvolvimento e operações.

2.2 Organização por naipes e severidade

Agrupamos as cartas em quatro naipes, cada um correspondente a uma camada da arquitetura, conforme o Quadro 2.

Quadro 2 – Naipes do ChaosEngineeringMasterDeck

Naipe	Camada	Exemplos de experimentos
Rede	Comunicação entre serviços	Latência elevada, perda de pacotes, partição de rede, falha de resolução DNS
Computação	Instâncias, contêineres e zonas	Encerramento de pods, saturação de CPU, perda de uma zona de disponibilidade
Dados	Bancos de dados, cache e filas	Failover de banco de dados, indisponibilidade de cache, acúmulo de mensagens
Dependências	Serviços internos e externos	Indisponibilidade de gateway de pagamento, API externa retornando HTTP 503

Fonte: elaborado pelo autor.

Cada carta possui ainda um nível de severidade de 1 a 5. Estabelecemos uma regra de progressão segundo a qual equipes iniciantes executam apenas cartas de níveis 1 e 2, e cartas de níveis 4 e 5, como a perda de uma região inteira, só são habilitadas após a execução bem-sucedida das cartas de menor severidade do mesmo naipe. Com essa regra, aplicamos o princípio de minimização do Blast Radius no nível do programa de experimentos, e não apenas no nível de cada experimento individual.

2.3 Estrutura de uma carta

Estruturei as cartas de acordo com as etapas do método científico. A Figura 1 apresenta o modelo que utilizamos.

Figura 1 – Modelo de carta do ChaosEngineeringMasterDeck

+------------------------------------------------+
| [NAIPE]-[NÚMERO]                 Severidade: N |
| Título do experimento                          |
+------------------------------------------------+
| HIPÓTESE                                       |
|   Se [falha], então [estado estável se mantém],|
|   porque [mecanismo de resiliência].           |
|                                                |
| ESTADO ESTÁVEL       métricas e valores-base   |
| VARIÁVEL INJETADA    tipo, intensidade, tempo  |
| BLAST RADIUS         limite máximo de impacto  |
| CONDIÇÃO DE ABORTO   critérios de interrupção  |
| ROLLBACK             procedimento de reversão  |
+------------------------------------------------+

Fonte: elaborado pelo autor.

Os campos têm as seguintes funções:

Hipótese: deve ser formulada obrigatoriamente no padrão "Se [falha], então [o estado estável se mantém], porque [mecanismo de resiliência]". Insisti na exigência da cláusula causal porque ela impede que executemos experimentos nos quais não conseguimos identificar o mecanismo que deveria proteger o sistema, o que por si só já constitui um achado relevante.
Estado estável: conjunto de métricas que caracterizam o comportamento normal do sistema, com seus respectivos valores de referência.
Variável injetada: a variável independente do experimento, especificada por tipo, alvo, intensidade, proporção do tráfego afetado e duração.
Métricas de controle: as mesmas métricas do estado estável, que comparamos entre um grupo de controle, não submetido à falha, e um grupo experimental.
Blast Radius: delimitação do impacto máximo admissível em termos de ambiente, usuários, serviços e tempo.
Condição de aborto: limiares cuja violação interrompe o experimento automaticamente.

3. Estudo de Caso: Latência em Dependência Crítica

3.1 Nota metodológica

O cenário que descrevo nesta seção é um estudo de caso construído para fins didáticos. A arquitetura, as configurações e os procedimentos refletem práticas reais de mercado. Os valores numéricos que apresento nas Tabelas 1 e 2 são ilustrativos: defini-os de modo a manter coerência interna entre as métricas, e eles não correspondem a medições de um ambiente produtivo específico.

3.2 Arquitetura do sistema

A plataforma em que trabalho é composta por microsserviços desenvolvidos em Spring Boot e executados no Amazon Elastic Kubernetes Service (EKS), distribuídos em três zonas de disponibilidade na região sa-east-1 (São Paulo). A Figura 2 apresenta o fluxo de criação de pedidos, que consideramos o fluxo crítico do negócio.

Figura 2 – Fluxo de criação de pedidos

                    +-------------+
   Cliente -------> | API Gateway |
                    +------+------+
                           |
                    +------v---------+       +-------------------+
                    | order-service  | ----> | inventory-service |
                    | (Spring Boot   |       |   (Spring Boot)   |
                    | + Resilience4j)|       +---------+---------+
                    +------+---------+                 |
                           |                   +-------v-------+
                    +------v--------+          |  Amazon RDS   |
                    |payment-service|          | (PostgreSQL)  |
                    +---------------+          +---------------+

Fonte: elaborado pelo autor.

O order-service consulta o inventory-service de forma síncrona para verificar a disponibilidade de estoque antes de confirmar cada pedido. Por se tratar de uma dependência síncrona situada no caminho crítico, identifiquei sua degradação como o principal risco de propagação de falhas em nossa arquitetura.

3.3 Especificação do experimento

A carta que selecionamos para o GameDay foi a REDE-07, cuja especificação apresento na Listagem 1.

Listagem 1 – Especificação da carta REDE-07

id: REDE-07
naipe: rede
severidade: 2
titulo: "Latência na Dependência Crítica"

hipotese: >
  Se o inventory-service responder com acréscimo de 2000 ms de latência,
  a taxa de sucesso na criação de pedidos permanecerá acima de 99%
  e a latência p99 do order-service permanecerá abaixo de 800 ms,
  porque o Circuit Breaker será aberto e o fallback utilizará
  o cache de estoque.

estado_estavel:
  - metrica: taxa_sucesso_pedidos
    referencia: ">= 99.5%"
  - metrica: latencia_p99_order_service
    referencia: "< 450 ms"
  - metrica: pedidos_por_minuto
    referencia: "variação < 5% em relação ao grupo de controle"

variavel_injetada:
  tipo: latencia
  alvo: order-service -> inventory-service
  latencia_ms: 2000
  jitter_ms: 300
  percentual_trafego: 10
  duracao: 10m
  ferramenta: toxiproxy

blast_radius:
  ambiente: producao-canary
  escopo: "pods do order-service no grupo canary (5% dos usuários)"
  impacto_maximo: "aproximadamente 0,5% das requisições de criação de pedido"
  servicos_excluidos: [payment-service, auth-service]

condicao_aborto:
  - "taxa de erro HTTP 5xx no canary > 2% por mais de 1 minuto"
  - "latência p99 no canary > 3000 ms por mais de 2 minutos"
  - "disparo de qualquer alerta de severidade P1"

rollback: "remoção do toxic de latência no Toxiproxy"

Fonte: elaborado pelo autor.

3.4 Delimitação do Blast Radius

O Blast Radius corresponde à extensão máxima do impacto caso a hipótese se revele falsa. Neste experimento, delimitei-o em três dimensões complementares:

Ambiente: restringimos o experimento ao grupo canary, que recebe 5% do tráfego real por meio de roteamento ponderado no API Gateway.
Tráfego: dentro do grupo canary, submetemos à latência apenas 10% das chamadas ao inventory-service.
Tempo: fixamos a duração máxima em 10 minutos, com interrupção automática em caso de violação das condições de aborto.

O produto dessas restrições resulta em um impacto máximo estimado de 0,5% das requisições de criação de pedido durante, no máximo, 10 minutos. Antes da execução, apresentei esse nível de risco à área de produto, que o aceitou formalmente.

Optei pelo ambiente produtivo, e não apenas pelo de homologação (staging), com base no terceiro princípio do Chaos Engineering. Em minha experiência, volume de tráfego, padrões de acesso e dimensionamento de pools de conexão raramente são reproduzidos com fidelidade em homologação, e diversas fragilidades de resiliência só se manifestam sob carga real. Para equipes em estágio inicial de maturidade, contudo, considero o ambiente de homologação um ponto de partida adequado.

3.5 Injeção da falha

Injetei a latência por meio do Toxiproxy, proxy TCP de código aberto desenvolvido pela Shopify para simulação de condições adversas de rede (SHOPIFY, 2024). Implantamos o proxy como contêiner auxiliar (sidecar) nos pods do order-service, interceptando as conexões destinadas ao inventory-service. A Listagem 2 apresenta o comando que utilizei.

Listagem 2 – Injeção de latência com o Toxiproxy

toxiproxy-cli toxic add \
  --type latency \
  --attribute latency=2000 \
  --attribute jitter=300 \
  --toxicity 0.1 \
  --toxicName latency_inventory \
  inventory

Fonte: elaborado pelo autor.

4. Observabilidade e Resultados

4.1 Instrumentação

Antes de injetar qualquer falha, precisei garantir que conseguíamos medir o estado estável. A instrumentação que utilizamos foi composta pelos seguintes elementos:

Micrometer e Prometheus: coleta de métricas dos serviços Spring Boot por meio do Spring Boot Actuator.
Grafana: painel que criei especificamente para o experimento, com exibição simultânea das métricas do grupo de controle e do grupo canary.
OpenTelemetry e Jaeger: rastreamento distribuído para identificar como o tempo de resposta se distribuía entre os serviços.
Alertmanager: avaliação contínua das condições de aborto.

A Listagem 3 apresenta as consultas PromQL que utilizei para as principais métricas de controle.

Listagem 3 – Consultas PromQL das métricas de controle

# Latência p99 do order-service, segmentada por grupo
histogram_quantile(0.99,
  sum(rate(http_server_requests_seconds_bucket{service="order-service", uri="/orders"}[1m]))
  by (le, group)
)

# Taxa de erros HTTP 5xx, segmentada por grupo
sum(rate(http_server_requests_seconds_count{service="order-service", status=~"5.."}[1m])) by (group)
/
sum(rate(http_server_requests_seconds_count{service="order-service"}[1m])) by (group)

# Estado do Circuit Breaker (valor 1 indica estado aberto)
resilience4j_circuitbreaker_state{name="inventory", state="open"}

Fonte: elaborado pelo autor.

4.2 Primeira execução: refutação da hipótese

A Listagem 4 apresenta a configuração de resiliência que estava vigente no order-service antes do experimento.

Listagem 4 – Configuração original do Resilience4j

resilience4j:
  circuitbreaker:
    instances:
      inventory:
        sliding-window-size: 100
        failure-rate-threshold: 50
        wait-duration-in-open-state: 30s

Fonte: elaborado pelo autor.

Só ao analisar essa configuração em retrospecto percebi que ela não definia limite de tempo para as chamadas remotas nem critério de classificação de chamadas lentas. O Circuit Breaker contabilizava apenas exceções, de modo que uma chamada concluída com sucesso após 2 segundos não era registrada como falha. A Tabela 1 apresenta as métricas que observei nos primeiros quatro minutos.

Tabela 1 – Métricas da primeira execução

Métrica	Grupo de controle	Grupo canary	Referência	Resultado
Taxa de sucesso	99,7%	98,1%	≥ 99,5%	Não atendido
Latência p99	410 ms	2.380 ms	< 450 ms	Não atendido
Estado do Circuit Breaker	Fechado	Fechado	Abertura esperada	Não atendido
Ocupação do pool de threads (Tomcat)	22%	91%	—	Anomalia

Fonte: dados ilustrativos elaborados pelo autor.

Ao analisar os rastros no Jaeger, identifiquei o mecanismo de propagação da falha. As chamadas lentas ao inventory-service mantinham ocupadas as threads do servidor Tomcat. Com menos threads disponíveis, mesmo as requisições não submetidas à latência passaram a aguardar em fila. Assim, uma degradação aplicada a apenas 10% das chamadas comprometeu o desempenho de praticamente todo o grupo canary.

A violação da condição de aborto relativa à latência p99 interrompeu o experimento automaticamente no quarto minuto. A remoção da latência no Toxiproxy levou menos de cinco segundos, e as métricas retornaram aos valores de referência em aproximadamente 40 segundos.

Não interpreto a refutação da hipótese como insucesso do experimento, mas como seu resultado mais informativo. Com impacto limitado a cerca de 0,5% das requisições durante quatro minutos, identificamos uma fragilidade que, em um incidente real envolvendo a degradação do inventory-service, poderia comprometer a totalidade da criação de pedidos.

4.3 Medidas corretivas

Para corrigir o problema, adotamos de forma combinada quatro padrões de resiliência descritos por Nygard (2018), implementados por meio da biblioteca Resilience4j (RESILIENCE4J, 2024). A Listagem 5 apresenta a configuração resultante.

Listagem 5 – Configuração revisada do Resilience4j

resilience4j:
  circuitbreaker:
    instances:
      inventory:
        sliding-window-size: 50
        failure-rate-threshold: 50
        slow-call-rate-threshold: 30
        slow-call-duration-threshold: 500ms
        wait-duration-in-open-state: 15s
        permitted-number-of-calls-in-half-open-state: 5
  timelimiter:
    instances:
      inventory:
        timeout-duration: 800ms
  bulkhead:
    instances:
      inventory:
        max-concurrent-calls: 20

Fonte: elaborado pelo autor.

A Listagem 6 mostra como apliquei os padrões no código do serviço.

Listagem 6 – Aplicação dos padrões de resiliência no order-service

@CircuitBreaker(name = "inventory", fallbackMethod = "estoqueDoCache")
@TimeLimiter(name = "inventory")
@Bulkhead(name = "inventory", type = Bulkhead.Type.THREADPOOL)
public CompletableFuture<Estoque> consultarEstoque(String produtoId) {
    return CompletableFuture.supplyAsync(() -> inventoryClient.buscar(produtoId));
}

private CompletableFuture<Estoque> estoqueDoCache(String produtoId, Throwable ex) {
    log.warn("Fallback de estoque acionado para {}: {}", produtoId, ex.getMessage());
    return CompletableFuture.completedFuture(
        estoqueCache.ultimoValorConhecido(produtoId).comFlagReconciliacao()
    );
}

Fonte: elaborado pelo autor.

Cada padrão cumpre uma função específica:

Time Limiter: impõe limite de 800 ms para cada chamada ao inventory-service, impedindo que threads permaneçam ocupadas indefinidamente.
Bulkhead: isola as chamadas ao inventory-service em um pool de threads dedicado, de modo que sua saturação não comprometa os demais fluxos do order-service.
Circuit Breaker com limiar de chamadas lentas: passa a considerar chamadas acima de 500 ms no cálculo de abertura do circuito, interrompendo tentativas contra uma dependência degradada.
Fallback: com o circuito aberto, o pedido é registrado com base no último valor de estoque conhecido no cache e marcado para reconciliação assíncrona. Essa foi uma decisão de negócio que tomamos em conjunto com a área de produto: consideramos preferível aceitar o pedido com pequeno risco de divergência de estoque a recusar a venda.

4.4 Segunda execução: confirmação da hipótese

Após implantarmos as correções, executei novamente a carta REDE-07 com os mesmos parâmetros. A Tabela 2 apresenta os resultados.

Tabela 2 – Métricas da segunda execução

Métrica	Grupo de controle	Grupo canary	Referência	Resultado
Taxa de sucesso	99,7%	99,6%	≥ 99,5%	Atendido
Latência p99	405 ms	790 ms	< 800 ms (hipótese)	Atendido
Estado do Circuit Breaker	Fechado	Aberto após ~20 s	Abertura esperada	Atendido
Chamadas atendidas por fallback	0%	~9%	—	Conforme esperado
Ocupação do pool de threads (Tomcat)	21%	26%	—	Normal

Fonte: dados ilustrativos elaborados pelo autor.

Desta vez, o experimento transcorreu durante os 10 minutos previstos sem violar nenhuma condição de aborto. Observei o Circuit Breaker alternar entre os estados aberto e semiaberto conforme o esperado, e a latência p99 manteve-se imediatamente abaixo do limite imposto pelo Time Limiter.

Faço, porém, uma ressalva: a latência p99 do grupo canary aumentou de aproximadamente 400 ms para 790 ms. A hipótese foi confirmada, mas o sistema não se tornou imune à falha; passou a degradar de forma controlada e previsível. Considero essa distinção central para a compreensão da resiliência, que não corresponde à ausência de falhas, mas à capacidade de manter o serviço em níveis aceitáveis durante sua ocorrência.

4.5 Incorporação ao processo contínuo

Com a hipótese confirmada, incorporei a carta REDE-07 à nossa suíte de experimentos automatizados, e ela passou a ser executada semanalmente no grupo canary. Dessa forma, eventuais regressões, como a remoção acidental do Time Limiter em uma refatoração futura, serão detectadas antes de se manifestarem em um incidente real. Com essa etapa, atendemos ao quarto princípio do Chaos Engineering, que recomenda a automação contínua dos experimentos.

5. Conclusão

A experiência relatada neste artigo me mostrou, na prática, que o Chaos Engineering cumpre a função de substituir suposições por evidências. Antes de executarmos a carta REDE-07, eu e minha equipe acreditávamos que o Circuit Breaker protegia o sistema contra a degradação do inventory-service. O experimento refutou essa crença e revelou um mecanismo de falha em cascata que nossos testes funcionais não teriam identificado.

Desse experimento, extraio as seguintes lições:

A latência é mais danosa que a indisponibilidade. Um serviço indisponível falha rapidamente, enquanto um serviço lento consome recursos de forma silenciosa até comprometer os serviços que dele dependem.
A resiliência resulta da combinação de padrões. No caso que analisei, o Circuit Breaker sem limite de tempo foi ineficaz contra chamadas lentas.
Hipóteses refutadas são os resultados de maior valor. Experimentos que apenas confirmam o comportamento esperado produzem pouco conhecimento novo.
A observabilidade é pré-requisito do experimento. Sem a capacidade de medir o estado estável, a injeção de falhas deixa de ser experimentação e passa a ser apenas uma fonte de instabilidade.
A delimitação do Blast Radius viabiliza o aprendizado com baixo risco. Um impacto de aproximadamente 0,5% das requisições durante quatro minutos nos permitiu identificar uma falha com potencial de afetar a totalidade do fluxo de pedidos.

No plano organizacional, percebi que o formato de baralho reduziu a percepção da prática como atividade de auditoria e favoreceu a participação conjunta das equipes de desenvolvimento e operações. Esse efeito reforçou, em nossa equipe, três fundamentos da cultura DevOps: a responsabilidade compartilhada, pois quem desenvolve o código passou a participar da análise de como ele falha em produção; o ciclo de retorno rápido, pois passamos a descobrir falhas em sessões controladas, e não durante plantões; e a melhoria contínua, pois cada hipótese refutada gera uma correção, e cada correção passa a ser verificada por um experimento automatizado.

Para quem pretende iniciar essa prática, recomendo uma abordagem incremental: selecionar uma única dependência crítica, formular uma hipótese no padrão "Se... então... porque...", delimitar um Blast Radius reduzido, definir condições de aborto objetivas e conduzir o primeiro experimento em ambiente de homologação. Como próximos passos, pretendo estender a análise a cartas de maior severidade, como a perda de uma zona de disponibilidade, e avaliar quantitativamente o efeito do programa de experimentos sobre indicadores como o tempo médio de recuperação (MTTR) e a frequência de incidentes.

Referências

BASIRI, A. et al. Chaos Engineering. IEEE Software, v. 33, n. 3, p. 35-41, 2016.

BEYER, B. et al. Site Reliability Engineering: how Google runs production systems. Sebastopol: O'Reilly Media, 2016.

NYGARD, M. T. Release It!: design and deploy production-ready software. 2. ed. Raleigh: Pragmatic Bookshelf, 2018.

PRINCIPLES OF CHAOS ENGINEERING. Principles of Chaos Engineering. 2019. Disponível em: https://principlesofchaos.org/. Acesso em: 15 out. 2026.

RESILIENCE4J. Resilience4j documentation. 2024. Disponível em: https://resilience4j.readme.io/. Acesso em: 15 out. 2026.

ROSENTHAL, C.; JONES, N. Chaos Engineering: system resiliency in practice. Sebastopol: O'Reilly Media, 2020.

SHOPIFY. Toxiproxy. 2024. Disponível em: https://github.com/Shopify/toxiproxy. Acesso em: 15 out. 2026.

Strategy Pattern em Java: Isolando Regras de Cálculo Fiscal em um Sistema B2B

Leticia Reis — Tue, 08 Sep 2026 13:23:19 +0000

Como separar regras de negócio que mudam em ritmos diferentes — e por que o switch é o lugar errado para elas.

Introdução

O Strategy é um Padrão de Projeto Comportamental, catalogado originalmente pela Gang of Four. Padrões comportamentais tratam de como objetos se comunicam e distribuem responsabilidades entre si — diferente dos criacionais, que tratam de como objetos são instanciados, e dos estruturais, que tratam de como objetos se compõem.

A definição formal é curta: o Strategy encapsula uma família de algoritmos intercambiáveis, cada um em sua própria classe, e permite que o algoritmo varie independentemente do cliente que o utiliza.

A definição prática é ainda mais curta: é o padrão que transforma a pergunta "qual regra eu aplico agora?" de uma estrutura condicional em uma escolha de objeto.

O problema: o `switch` que ninguém quer tocar

Todo sistema que cresce acumula um método específico. Ele começa com dois casos, ganha um terceiro em uma sprint apertada e, alguns anos depois, tem centenas de linhas e um comentário do tipo // não mexer sem falar com o time de faturamento.

O sintoma visível é feio, mas o sintoma não é o problema. O problema real é acoplamento temporal: regras que mudam em cadências independentes foram colocadas fisicamente na mesma unidade de código.

Quando a regra A muda, você é obrigado a abrir, recompilar e reimplantar o mesmo arquivo que executa a regra B — mesmo que B não tenha mudado nada.

Isso transforma cada alteração pequena em risco grande. E risco grande produz um comportamento defensivo previsível: ninguém quer mexer no método, então as pessoas contornam com condicionais extras em vez de corrigir a estrutura, e o método piora a cada iteração.

O Strategy ataca exatamente esse acoplamento. Ele separa o que varia do que permanece estável, colocando cada variação em uma classe própria.

Conceito: a analogia da fonte de energia

Pense em um notebook e nas tomadas do mundo. O notebook não tem, internamente, uma estrutura condicional perguntando "estou no Brasil? estou no Reino Unido? estou no Japão?" para decidir como converter a energia. Se tivesse, cada país novo exigiria um firmware novo no notebook.

O que existe é um contrato: a fonte entrega uma tensão estável ao notebook. Como essa tensão foi obtida — de 127V, 220V ou 240V — é problema de quem implementa o contrato, não de quem o consome.

O Strategy é isso em código:

O contrato é uma interface.
Cada variação do algoritmo é uma classe que implementa essa interface.
O contexto (o notebook) conhece apenas a interface, nunca as implementações concretas.

A consequência importante: a lógica que decide como calcular fica isolada da lógica que decide quando calcular.

Estudo de caso: motor de cálculo fiscal em um sistema B2B

Para demonstrar o padrão em um contexto mais próximo dos desafios encontrados em sistemas corporativos, vamos utilizar como exemplo um motor de cálculo fiscal em uma plataforma B2B.

⚠️ Aviso: Os valores, alíquotas e fórmulas apresentados neste artigo são simplificados e possuem finalidade exclusivamente didática. Eles não devem ser utilizados para cálculo tributário real ou tomada de decisão fiscal.

O sistema legado

A plataforma emite notas para clientes de perfis diferentes, e o valor dos tributos depende do regime tributário do cliente: Simples Nacional, Lucro Presumido ou Lucro Real. O código original concentrava tudo em um único método:

public BigDecimal calcularImpostos(Pedido pedido, Cliente cliente) {
    BigDecimal total = BigDecimal.ZERO;

    if (cliente.getRegime().equals("SIMPLES")) {
        // faixas de receita, parcela a deduzir, alíquota efetiva
    } else if (cliente.getRegime().equals("PRESUMIDO")) {
        // alíquotas fixas sobre a receita
    } else if (cliente.getRegime().equals("REAL")) {
        // alíquotas maiores, com desconto de créditos apropriados
    }

    return total;
}

Por que isso é um problema de engenharia, e não só código feio

Três características desse domínio tornam o acoplamento caro:

1. As regras mudam em datas diferentes e por motivos diferentes. Cada regime segue sua própria trilha legislativa. Uma alteração em um não tem relação nenhuma com o outro, mas ambos vivem no mesmo arquivo.

2. Os algoritmos consomem entradas diferentes. O Simples precisa da receita bruta acumulada do cliente para descobrir em qual faixa ele está. O Lucro Real precisa dos créditos apropriados no período. O Lucro Presumido não usa nenhum dos dois. Não existe "extrair um método comum" aqui, porque os inputs divergem.

3. O raio de explosão de um erro é o faturamento inteiro. Uma regressão introduzida ao ajustar a faixa do Simples pode derrubar a emissão de notas dos clientes de Lucro Real, porque compartilham o mesmo caminho de execução.

Esse é o formato clássico de problema que o Strategy resolve: variação de algoritmo, com cadência de mudança independente e alto custo de erro. A partir daqui, o foco é o padrão; a parte fiscal existe apenas para dar peso realista ao cenário.

Escopo do exemplo

Para manter o artigo focado no padrão, as alíquotas e faixas são constantes dentro de cada estratégia. Em um sistema real elas viriam de configuração versionada com data de vigência — uma decisão de infraestrutura ortogonal ao Strategy. Todo o código apresentado abaixo é Java puro e compila sem framework.

Representação visual

Figura 1 — Diagrama UML do Strategy Pattern aplicado ao motor fiscal.

O diagrama está restrito às classes que compõem o padrão. Pedido, Cliente e as exceções aparecem no código como tipos de apoio, mas incluí-los aqui tiraria o foco da estrutura que importa.

Repare no losango vazio, indicando agregação, entre MotorFiscal e CalculadoraImposto: o motor usa as estratégias, mas não as cria. Esse detalhe é o que separa um Strategy real de um switch disfarçado.

Figura 2 — Arquitetura de alto nível do sistema de cálculo fiscal.

Dois pontos que este desenho comunica e o UML não:

A consulta ao banco acontece antes do motor. É o dado do cliente que determina qual estratégia será executada — a seleção não é uma decisão tomada em código, é uma consequência de dados que chegam em tempo de execução.
O Módulo Fiscal é uma fronteira interna, não um serviço remoto. O Strategy aqui é uma decisão de organização interna. Ele não introduz nenhuma chamada de rede, e é importante que isso fique visível: padrões de projeto e padrões de arquitetura distribuída resolvem problemas diferentes.

Implementação em Java

Tipos de apoio

public enum RegimeTributario {
    SIMPLES_NACIONAL,
    LUCRO_PRESUMIDO,
    LUCRO_REAL
}

public record Cliente(RegimeTributario regimeTributario, BigDecimal receitaBruta12Meses, String uf) {}

public record Pedido(BigDecimal valorTotal, BigDecimal creditosApropriados) {}

public class RegimeNaoSuportadoException extends RuntimeException {
    public RegimeNaoSuportadoException(RegimeTributario regime) {
        super("Nenhuma calculadora registrada para o regime: " + regime);
    }
}

public class LimiteSimplesExcedidoException extends RuntimeException {
    public LimiteSimplesExcedidoException(BigDecimal receita) {
        super("Receita acumulada fora das faixas configuradas: " + receita);
    }
}

O contrato

public record ContextoFiscal(
        BigDecimal valorBruto,
        BigDecimal receitaBruta12Meses,
        BigDecimal creditosApropriados,
        String uf
) {
    public static ContextoFiscal de(Pedido pedido, Cliente cliente) {
        return new ContextoFiscal(
                pedido.valorTotal(),
                cliente.receitaBruta12Meses(),
                pedido.creditosApropriados(),
                cliente.uf()
        );
    }
}

public record ResultadoImposto(
        BigDecimal total,
        RegimeTributario regimeAplicado,
        Map<String, BigDecimal> detalhamento
) {}

public interface CalculadoraImposto {

    ResultadoImposto calcular(ContextoFiscal contexto);

    RegimeTributario getRegime();
}

O método getRegime() merece atenção. Ele existe para que cada estratégia se identifique, em vez de alguém externo precisar mapeá-la. É esse detalhe que permite eliminar a estrutura condicional de verdade, em vez de apenas empurrá-la para uma factory.

As estratégias

public class SimplesNacionalCalculadora implements CalculadoraImposto {

    private record Faixa(BigDecimal limite, BigDecimal aliquotaNominal, BigDecimal parcelaDeduzir) {}

    // Tabela reduzida e simplificada para fins didáticos.
    private static final List<Faixa> FAIXAS = List.of(
            new Faixa(bd("180000"),  bd("0.0400"), bd("0")),
            new Faixa(bd("360000"),  bd("0.0730"), bd("5940")),
            new Faixa(bd("720000"),  bd("0.0950"), bd("13860")),
            new Faixa(bd("1800000"), bd("0.1070"), bd("22500"))
    );

    @Override
    public ResultadoImposto calcular(ContextoFiscal contexto) {
        BigDecimal receita = contexto.receitaBruta12Meses();

        Faixa faixa = FAIXAS.stream()
                .filter(f -> receita.compareTo(f.limite()) <= 0)
                .findFirst()
                .orElseThrow(() -> new LimiteSimplesExcedidoException(receita));

        // Alíquota efetiva = (receita x alíquota nominal - parcela a deduzir) / receita
        BigDecimal aliquotaEfetiva = receita.multiply(faixa.aliquotaNominal())
                .subtract(faixa.parcelaDeduzir())
                .divide(receita, 6, RoundingMode.HALF_UP);

        BigDecimal imposto = contexto.valorBruto()
                .multiply(aliquotaEfetiva)
                .setScale(2, RoundingMode.HALF_UP);

        return new ResultadoImposto(
                imposto,
                RegimeTributario.SIMPLES_NACIONAL,
                Map.of("IMPOSTO_UNIFICADO", imposto, "ALIQUOTA_EFETIVA", aliquotaEfetiva)
        );
    }

    @Override
    public RegimeTributario getRegime() {
        return RegimeTributario.SIMPLES_NACIONAL;
    }

    private static BigDecimal bd(String valor) {
        return new BigDecimal(valor);
    }
}

public class LucroPresumidoCalculadora implements CalculadoraImposto {

    // Alíquotas ilustrativas.
    private static final BigDecimal ALIQUOTA_A = new BigDecimal("0.0065");
    private static final BigDecimal ALIQUOTA_B = new BigDecimal("0.0300");

    @Override
    public ResultadoImposto calcular(ContextoFiscal contexto) {
        BigDecimal base = contexto.valorBruto();

        BigDecimal tributoA = base.multiply(ALIQUOTA_A).setScale(2, RoundingMode.HALF_UP);
        BigDecimal tributoB = base.multiply(ALIQUOTA_B).setScale(2, RoundingMode.HALF_UP);

        return new ResultadoImposto(
                tributoA.add(tributoB),
                RegimeTributario.LUCRO_PRESUMIDO,
                Map.of("TRIBUTO_A", tributoA, "TRIBUTO_B", tributoB)
        );
    }

    @Override
    public RegimeTributario getRegime() {
        return RegimeTributario.LUCRO_PRESUMIDO;
    }
}

public class LucroRealCalculadora implements CalculadoraImposto {

    // Alíquotas ilustrativas.
    private static final BigDecimal ALIQUOTA_A = new BigDecimal("0.0165");
    private static final BigDecimal ALIQUOTA_B = new BigDecimal("0.0760");

    @Override
    public ResultadoImposto calcular(ContextoFiscal contexto) {
        BigDecimal base = contexto.valorBruto().subtract(contexto.creditosApropriados())
                .max(BigDecimal.ZERO);

        BigDecimal tributoA = base.multiply(ALIQUOTA_A).setScale(2, RoundingMode.HALF_UP);
        BigDecimal tributoB = base.multiply(ALIQUOTA_B).setScale(2, RoundingMode.HALF_UP);

        return new ResultadoImposto(
                tributoA.add(tributoB),
                RegimeTributario.LUCRO_REAL,
                Map.of("TRIBUTO_A", tributoA, "TRIBUTO_B", tributoB,
                       "CREDITOS", contexto.creditosApropriados())
        );
    }

    @Override
    public RegimeTributario getRegime() {
        return RegimeTributario.LUCRO_REAL;
    }
}

LucroRealCalculadora usa creditosApropriados e ignora receitaBruta12Meses; SimplesNacionalCalculadora faz o oposto.

Essa assimetria é a justificativa técnica do padrão: não são parâmetros diferentes do mesmo algoritmo, são algoritmos diferentes.

O contexto: onde a condicional desaparece

public class MotorFiscal {

    private final Map<RegimeTributario, CalculadoraImposto> estrategias;

    public MotorFiscal(List<CalculadoraImposto> calculadoras) {
        this.estrategias = calculadoras.stream()
                .collect(Collectors.toUnmodifiableMap(
                        CalculadoraImposto::getRegime,
                        Function.identity()
                ));
    }

    public ResultadoImposto calcularPara(Pedido pedido, Cliente cliente) {
        CalculadoraImposto calculadora = estrategias.get(cliente.regimeTributario());

        if (calculadora == null) {
            throw new RegimeNaoSuportadoException(cliente.regimeTributario());
        }

        return calculadora.calcular(ContextoFiscal.de(pedido, cliente));
    }
}

Este é o coração do artigo. Duas decisões merecem ser explicadas.

Collectors.toUnmodifiableMap falha na inicialização se houver regime duplicado. Se alguém criar por engano uma segunda calculadora para LUCRO_REAL, o coletor lança IllegalStateException na construção do objeto. Isso é bem melhor do que descobrir em produção que parte das notas usou a implementação errada.

A escolha entre exceção e valor padrão é uma decisão de domínio, não do padrão. Aqui a exceção é deliberada: em cálculo tributário, "não sei calcular" precisa interromper a operação, porque um valor padrão silencioso geraria um documento incorreto. Em outros domínios — formatação de texto, política de desconto — um comportamento padrão neutro seria a escolha certa.

Vale notar que o construtor recebe uma List justamente para desacoplar o motor de quem monta as estratégias. Em uma aplicação com injeção de dependência, essa lista é preenchida automaticamente; em Java puro, ela é passada na composição da aplicação. O motor não muda em nenhum dos dois casos.

O que realmente muda ao adicionar um regime novo

É comum ler que o Strategy permite estender o sistema "sem alterar nenhuma linha de código existente". Na implementação acima, isso não é literalmente verdade, e vale ser preciso.

Para adicionar um regime novo, é preciso:

Acrescentar uma constante em RegimeTributario — uma linha, aditiva.
Criar uma classe nova implementando CalculadoraImposto e registrá-la na composição da aplicação.

O que não muda:

MotorFiscal não é tocado.
Nenhuma das calculadoras existentes é tocada.
O código que consome o resultado não é tocado.

A diferença em relação ao switch original é qualitativa, não quantitativa. Lá, você também acrescentaria uma constante — mas depois editaria o mesmo método que executa o cálculo de todos os outros regimes. É essa segunda edição, no código que está em produção e funcionando, que carrega o risco de regressão.

O Strategy não elimina toda alteração; ele elimina a alteração perigosa.

Rigorosamente, o enum ainda é um ponto de extensão que exige modificação, e é justo chamar isso de violação parcial do Princípio Aberto/Fechado. Existe alternativa: usar String como chave do mapa, lida do banco de dados. Isso removeria até essa linha, ao custo de perder a verificação em tempo de compilação. Manter o enum é um trade-off consciente — em domínio fiscal, um regime escrito errado falhando no build é preferível a falhar em produção.

Testes

Cada estratégia é testável isoladamente, sem instanciar as outras. No método monolítico original, testar um regime exigia carregar todos juntos.

class MotorFiscalTest {

    private final MotorFiscal motor = new MotorFiscal(List.of(
            new SimplesNacionalCalculadora(),
            new LucroPresumidoCalculadora(),
            new LucroRealCalculadora()
    ));

    @Test
    void deveSelecionarEstrategiaConformeRegimeDoCliente() {
        var cliente = new Cliente(RegimeTributario.LUCRO_PRESUMIDO, new BigDecimal("500000"), "GO");
        var pedido = new Pedido(new BigDecimal("10000.00"), BigDecimal.ZERO);

        ResultadoImposto resultado = motor.calcularPara(pedido, cliente);

        assertThat(resultado.total()).isEqualByComparingTo("365.00");
        assertThat(resultado.regimeAplicado()).isEqualTo(RegimeTributario.LUCRO_PRESUMIDO);
    }

    @Test
    void deveAplicarAliquotaEfetivaNoSimplesNacional() {
        var cliente = new Cliente(RegimeTributario.SIMPLES_NACIONAL, new BigDecimal("500000"), "GO");
        var pedido = new Pedido(new BigDecimal("10000.00"), BigDecimal.ZERO);

        ResultadoImposto resultado = motor.calcularPara(pedido, cliente);

        assertThat(resultado.total()).isEqualByComparingTo("672.80");
    }

    @Test
    void deveFalharQuandoNaoHaEstrategiaParaORegime() {
        MotorFiscal motorIncompleto = new MotorFiscal(List.of(new LucroPresumidoCalculadora()));
        var cliente = new Cliente(RegimeTributario.LUCRO_REAL, new BigDecimal("500000"), "GO");
        var pedido = new Pedido(new BigDecimal("10000.00"), BigDecimal.ZERO);

        assertThatThrownBy(() -> motorIncompleto.calcularPara(pedido, cliente))
                .isInstanceOf(RegimeNaoSuportadoException.class);
    }
}

O terceiro teste é o mais interessante: ele documenta o comportamento na ausência de estratégia, que é justamente a decisão de domínio discutida acima.

Prós e contras

Vantagens

Extensão com risco contido. Adicionar um regime significa uma constante nova e uma classe nova. Nenhum algoritmo existente é editado.
Raio de explosão reduzido. Uma alteração no cálculo do Simples não pode quebrar o Lucro Real: não compartilham arquivo, estado nem caminho de execução.
Testabilidade real. Cada algoritmo é uma unidade isolada, com entradas e saídas explícitas.
Seleção dirigida por dados. Como a escolha vem do cadastro do cliente e não de código, fica natural evoluir para cenários como aplicar a regra vigente na data de emissão.

Custos e trade-offs

Dispersão da lógica. Antes, todas as regras estavam em uma tela; agora estão em vários arquivos. Para quem chega no time, "onde o imposto é calculado?" ficou mais difícil de responder.
Observabilidade vira requisito. Com a condicional, bastava ler o código para saber o que executou. Agora é preciso registrar qual implementação atendeu qual pedido — incluir regimeAplicado no ResultadoImposto é resposta direta a esse custo.
O objeto de contexto tende a inchar. ContextoFiscal carrega a união dos campos que qualquer estratégia possa precisar, então cada implementação ignora parte deles. É um efeito colateral conhecido do Strategy com contexto compartilhado.
Mais tipos para manter. Cinco classes onde havia um método. Em uma base pequena e estável, isso é cerimônia sem retorno.

E o trade-off mais importante: se a variação for de dados, Strategy é overengineering. Uma alíquota que muda por unidade da federação não merece uma classe por estado — isso é tabela de configuração.

O sinal prático para distinguir: se as implementações diferem apenas por constantes, você quer uma tabela. Se diferem nos campos que consomem e nos passos que executam, você quer Strategy. Foi esse teste que justificou o padrão aqui.

Conclusão

O Strategy não resolve o problema de "código feio com muitas condicionais". Ele resolve um problema arquitetural mais específico: regras de negócio que evoluem em ritmos independentes acopladas na mesma unidade de código.

No motor fiscal, o ganho não é estético. É transformar uma alteração de alto risco — mexer no cálculo de todos os clientes para atender à mudança de um regime — em uma alteração isolada e testável. O padrão desloca a modificação para o lugar barato, uma constante em um enum, e a tira do lugar caro, o algoritmo em produção.

Visão pessoal

Como estudante e desenvolvedora em formação, minha experiência com Padrões de Projeto até a realização deste estudo era majoritariamente teórica. Ao ler a literatura técnica, a princípio, o Strategy pode parecer apenas uma forma desnecessariamente complexa e verbosa de escrever uma estrutura condicional simples.

No entanto, o exercício de modelar e implementar este cenário de cálculo tributário mudou completamente minha perspectiva. A verdadeira virada de chave foi ver o Princípio Aberto/Fechado funcionando na prática: a compreensão de que podemos expandir as capacidades de um sistema inteiro apenas adicionando novas classes, sem a necessidade de alterar ou arriscar quebrar o código do motor principal.

Escrever este artigo também me obrigou a ser mais precisa do que eu esperava. Ao revisar a implementação, percebi que a afirmação comum de que o Strategy dispensa qualquer alteração no código existente não se sustenta inteiramente, já que o enum de regimes ainda precisa receber uma constante nova. Entender por que essa alteração é aceitável — e por que ela é qualitativamente diferente de editar o algoritmo em produção — foi provavelmente o que mais me ensinou no processo.

Ainda que eu não tenha vivenciado o cenário crítico de manter um sistema legado complexo em produção e lidar com as regressões causadas por um método fortemente acoplado, essa imersão prática cumpriu seu objetivo principal. Ela me forneceu a base arquitetural não apenas para entender como resolver esse tipo de problema, mas, principalmente, para evitar que eu construa sistemas com essas falhas de design no futuro.

E você?

Fica a pergunta que mais me interessa: qual foi a estrutura condicional mais assustadora que você já encontrou em produção — e você refatorou ou concluiu que o risco não valia a pena?

Também quero ouvir discordância: em que situação você acha que manter o switch foi a decisão certa? Comenta aí.

DEV Community: Leticia Reis

Resiliência por Experimentação: Aplicação do ChaosEngineeringMasterDeck na Validação de uma Arquitetura de Microsserviços em Nuvem

1. Introdução

1.1 Justificativa: por que provocar falhas intencionalmente

1.2 Mudança de paradigma

1.3 Princípios fundamentais

2. O ChaosEngineeringMasterDeck

2.1 Definição

2.2 Organização por naipes e severidade

2.3 Estrutura de uma carta

3. Estudo de Caso: Latência em Dependência Crítica

3.1 Nota metodológica

3.2 Arquitetura do sistema

3.3 Especificação do experimento

3.4 Delimitação do Blast Radius

3.5 Injeção da falha

4. Observabilidade e Resultados

4.1 Instrumentação

4.2 Primeira execução: refutação da hipótese

4.3 Medidas corretivas

4.4 Segunda execução: confirmação da hipótese

4.5 Incorporação ao processo contínuo

5. Conclusão

Referências

Strategy Pattern em Java: Isolando Regras de Cálculo Fiscal em um Sistema B2B

Introdução

O problema: o switch que ninguém quer tocar

Conceito: a analogia da fonte de energia

Estudo de caso: motor de cálculo fiscal em um sistema B2B

O sistema legado

Por que isso é um problema de engenharia, e não só código feio

Escopo do exemplo

Representação visual

Implementação em Java

Tipos de apoio

O contrato

As estratégias

O contexto: onde a condicional desaparece

O que realmente muda ao adicionar um regime novo

Testes

Prós e contras

Vantagens

Custos e trade-offs

Conclusão

Visão pessoal

E você?

O problema: o `switch` que ninguém quer tocar