Resiliência, recuperação e governança em sistemas distribuídos

Introdução

Falhas fazem parte da operação de qualquer sistema.

Elas podem ocorrer por:

• Problemas de infraestrutura
• Indisponibilidade de serviços externos
• Erros humanos
• Picos inesperados de acesso
• Falhas de rede
• Erros de configuração
• Atualizações defeituosas
• Dependências comprometidas
• Ataques
• Vulnerabilidades

O objetivo da arquitetura não é prometer que nenhuma falha acontecerá.

O objetivo é definir como o sistema responderá quando ela acontecer.

Uma arquitetura resiliente precisa conhecer seus limites.

Ela deve responder perguntas como:

• Quanto tempo uma dependência pode demorar?
• Quantas vezes uma operação pode ser repetida?
• O que acontece quando um serviço permanece indisponível?
• Como impedir que uma falha consuma todos os recursos?
• Existe uma alternativa degradada?
• Como evitar efeitos duplicados?
• Quanto dado o negócio aceita perder?
• Quanto tempo o sistema pode permanecer fora?

Padrões de resiliência

Os principais padrões abordados são:

• Timeout
• Retry
• Circuit Breaker
• Bulkhead
• Fallback
• Idempotência

Eles são complementares, mas não devem ser aplicados automaticamente em todas as operações.

Cada padrão resolve um problema diferente e também introduz custos e limitações.

Timeout

Timeout define o tempo máximo que uma aplicação aceita esperar pela resposta de uma dependência.

Sem timeout, uma chamada pode permanecer presa por tempo indeterminado, consumindo:

• Threads
• Conexões
• Memória
• Recursos computacionais
• Capacidade de atendimento

Exemplo

Serviço A
   ↓
Serviço B
   ↓
Limite de espera: 2 segundos

Se o Serviço B não responder dentro do limite, o Serviço A interrompe a espera e trata a falha.

O valor precisa considerar:

• Latência normal da dependência
• Percentis de resposta
• Criticidade da operação
• Experiência esperada pelo usuário
• Comportamento durante picos

Percentis

A média nem sempre representa corretamente o comportamento da dependência.

Uma operação pode possuir:

p50: 200 ms
p95: 900 ms
p99: 2,5 s

Um timeout definido apenas pela média poderia interromper uma parcela relevante das requisições válidas.

Retry

Retry consiste em realizar novamente uma operação que falhou.

Ele é adequado principalmente para falhas transitórias.

Falhas transitórias

• Timeout temporário
• Instabilidade de rede
• Serviço momentaneamente indisponível
• Limitação temporária de capacidade

Falhas permanentes

• Credenciais inválidas
• Dados incorretos
• Regra de negócio rejeitada
• Recurso inexistente
• Falta de permissão

Repetir uma operação com credenciais inválidas não corrige o problema.

Nesse cenário, o retry apenas aumenta a carga e atrasa a resposta final.

Exponential backoff

No exponential backoff, o intervalo entre as tentativas aumenta progressivamente.

Primeira repetição: 1 segundo
Segunda repetição: 2 segundos
Terceira repetição: 4 segundos
Quarta repetição: 8 segundos

Isso reduz a pressão sobre uma dependência que já está enfrentando problemas.

function calculateBackoff(attempt: number): number {
  return 2 ** attempt * 1_000;
}

Jitter

Jitter adiciona uma variação aleatória aos intervalos.

Sem essa variação, centenas ou milhares de instâncias podem repetir a chamada exatamente no mesmo momento.

Dependência começa a se recuperar
↓
Todas as instâncias repetem simultaneamente
↓
Novo pico de requisições
↓
Dependência volta a falhar

Exemplo conceitual:

function calculateBackoffWithJitter(attempt: number): number {
  const backoff = 2 ** attempt * 1_000;
  const jitter = Math.random() * 500;
 
  return backoff + jitter;
}

Amplificação de retries

Retries implementados em diferentes níveis podem multiplicar a quantidade de chamadas.

Considere:

Serviço A
├── Serviço B → Banco
└── Serviço C → Banco

Se B realizar três tentativas e C também realizar três tentativas, uma única operação iniciada em A pode produzir até seis chamadas ao banco.

Se A também possuir retry, a multiplicação pode ser ainda maior.

Possíveis consequências

• Retry storm
• Sobrecarga do banco
• Aumento da latência
• Esgotamento de conexões
• Propagação da falha
• Queda de outros serviços

Circuit Breaker

Circuit Breaker interrompe temporariamente as chamadas para uma dependência que está falhando.

A analogia é a de um disjuntor elétrico.

Quando um problema é detectado, o circuito é aberto para impedir que a falha continue se propagando.

Estados do Circuit Breaker

Closed

As chamadas seguem normalmente.

Open

As chamadas são bloqueadas imediatamente porque a dependência é considerada indisponível.

Half-open

Algumas chamadas de teste são permitidas para verificar se o serviço se recuperou.

Fluxo conceitual

Closed
↓
Falhas consecutivas
↓
Open
↓
Intervalo de recuperação
↓
Half-open
├── Sucesso → Closed
└── Falha → Open

Benefícios

• Evita sobrecarregar um serviço em falha
• Reduz o tempo de espera
• Impede falhas em cascata
• Permite recuperação gradual
• Protege recursos da aplicação chamadora

Bulkhead

Bulkhead significa isolar recursos utilizados por serviços ou operações diferentes.

O nome vem das divisórias internas utilizadas em navios.

Se uma parte da embarcação for inundada, as divisórias ajudam a impedir que a água comprometa todo o navio.

Na arquitetura, o isolamento pode ser aplicado a:

• Pools de threads
• Conexões
• Filas
• Processos
• Contêineres
• Instâncias
• Bancos de dados
• Recursos computacionais

Exemplo

Uma aplicação possui integrações com:

• Serviço de pagamento
• Serviço de e-mail
• Serviço de relatórios

Sem isolamento:

Pool compartilhado
├── Pagamentos
├── E-mails
└── Relatórios

Se o serviço de relatórios ficar lento e consumir todas as conexões, os pagamentos também podem parar.

Com Bulkhead:

Pool de pagamentos
Pool de e-mails
Pool de relatórios

A falha de uma integração fica contida.

Fallback

Fallback define uma alternativa quando o fluxo principal não pode ser concluído.

Exemplos:

• Exibir dados em cache
• Mostrar uma resposta simplificada
• Utilizar um provedor alternativo
• Colocar uma solicitação em fila
• Ocultar temporariamente uma funcionalidade
• Informar que o serviço está degradado

Exemplo

Se o serviço de recomendação estiver indisponível, um e-commerce pode exibir os produtos mais vendidos.

Recomendação personalizada indisponível
↓
Fallback
↓
Produtos mais vendidos

A jornada principal continua utilizável mesmo sem todas as funcionalidades.

Cuidado

Fallback não deve:

• Ocultar falhas críticas
• Produzir informações incorretas
• Simular sucesso quando a operação falhou
• Manter dados desatualizados sem indicação
• Comprometer requisitos legais ou financeiros

Idempotência

Uma operação idempotente pode ser repetida sem produzir efeitos adicionais incorretos.

Esse conceito é essencial quando existem:

• Retries
• Filas
• Eventos
• Reprocessamentos
• Falhas de rede

Exemplo de pagamento

Pagamento é enviado
↓
Pagamento é processado
↓
Resposta se perde na rede
↓
Cliente realiza nova tentativa

Sem idempotência, a segunda tentativa pode gerar uma nova cobrança.

Uma chave de idempotência permite reconhecer a mesma operação.

await paymentService.charge({
  idempotencyKey: "order-100-payment",
  orderId: "order-100",
  amount: 250,
});

Combinando os padrões

Um fluxo resiliente pode combinar os padrões da seguinte forma:

Requisição
↓
Timeout
↓
Retry com backoff e jitter
↓
Circuit Breaker
↓
Fallback

Ao redor do fluxo:

• Bulkhead isola os recursos.
• Idempotência protege contra duplicações.

A ordem e a aplicação exata dependem da biblioteca, da plataforma e do fluxo.

O importante é compreender a responsabilidade de cada padrão.

Cloud e responsabilidade operacional

Ao utilizar um provedor de nuvem, a organização reduz o controle direto sobre a infraestrutura física.

Isso não significa perder toda a responsabilidade.

A operação passa a seguir um modelo de responsabilidade compartilhada.

Possíveis responsabilidades do provedor

• Data centers
• Energia
• Hardware
• Rede física
• Serviços gerenciados

Responsabilidades que permanecem com a organização

Dependendo do serviço contratado:

• Configuração
• Identidades
• Permissões
• Dados
• Aplicações
• Monitoramento
• Custos
• Continuidade
• Segurança lógica
• Governança

FinOps e custo da resiliência

FinOps ajuda a controlar, compreender e justificar os custos da nuvem.

Resiliência possui impacto financeiro.

Exemplos:

• Mais regiões aumentam o custo
• Mais réplicas aumentam o custo
• Ambientes permanentemente ativos aumentam o custo
• Logs adicionais aumentam o custo
• Backups adicionais aumentam o custo
• Maior disponibilidade exige mais infraestrutura

A organização precisa saber quanto está pagando por cada nível de proteção.

Backup não é recuperação

Fazer backup é apenas uma parte da estratégia.

Um backup que nunca foi restaurado é apenas uma expectativa de proteção.

Para ser confiável, o processo precisa comprovar que:

• Os dados foram armazenados corretamente
• Os arquivos não estão corrompidos
• As credenciais de recuperação funcionam
• O ambiente pode ser reconstruído
• O tempo de restauração atende ao negócio
• As dependências estão disponíveis
• As equipes sabem executar o procedimento

O que precisa ser protegido

A estratégia pode incluir:

• Bancos de dados
• Volumes persistentes
• Arquivos
• Objetos armazenados
• Configurações
• Certificados
• Repositórios de código
• Imagens de máquinas
• Artefatos de implantação
• Infraestrutura como código
• Segredos, com controles específicos
• Documentação operacional

Contêineres

Contêineres normalmente são tratados como recursos descartáveis.

Em vez de fazer backup do contêiner em execução, costuma ser mais adequado preservar:

• A imagem no registry
• A configuração de implantação
• A infraestrutura como código
• Os volumes persistentes
• As versões dos artefatos

O estado importante não deveria existir apenas dentro de um contêiner efêmero.

Testes de restauração

O restore deve ser testado periodicamente.

Um teste pode verificar:

• Se o backup pode ser localizado
• Se ele pode ser descriptografado
• Se os dados podem ser restaurados
• Se a aplicação consegue utilizá-los
• Se as integrações continuam funcionando
• Quanto tempo o processo demora
• Quanto dado foi perdido

Os resultados podem gerar evidências para:

• Auditoria
• Governança
• Compliance
• Revisão dos objetivos de recuperação
• Melhoria dos procedimentos

Disaster Recovery

Disaster Recovery, ou DR, é o conjunto de estratégias utilizadas para restaurar serviços e dados após uma interrupção de grande impacto.

Possíveis desastres

• Falha completa de uma região
• Indisponibilidade de data center
• Ataque cibernético
• Corrupção de dados
• Exclusão acidental
• Incêndio
• Falha elétrica prolongada
• Comprometimento de credenciais
• Atualização destrutiva

Um plano de DR precisa responder:

• Quais serviços serão recuperados primeiro?
• Onde serão recuperados?
• Quem decide ativar a contingência?
• Como os dados serão restaurados?
• Como o tráfego será redirecionado?
• Como validar o ambiente?
• Como retornar ao ambiente principal?

RPO

RPO significa Recovery Point Objective.

Ele representa a quantidade máxima de dados que o negócio aceita perder, medida em tempo.

Exemplo

RPO: 15 minutos

Em um desastre, a empresa aceita perder no máximo os dados produzidos nos últimos quinze minutos.

Quanto menor o RPO, maior tende a ser a necessidade de:

• Replicação frequente
• Replicação contínua
• Mais armazenamento
• Mais tráfego de rede
• Maior custo

RTO

RTO significa Recovery Time Objective.

Ele representa o tempo máximo aceitável para restaurar o serviço.

Exemplo

RTO: 1 hora

O sistema deve voltar a operar em até uma hora após o incidente.

Quanto menor o RTO, maior tende a ser a necessidade de:

• Automação
• Infraestrutura previamente provisionada
• Ambientes de contingência
• Equipes disponíveis
• Testes frequentes
• Procedimentos claros

RPO e RTO

Um sistema pode possuir:

• RPO baixo e RTO alto
• RPO alto e RTO baixo
• Ambos baixos
• Ambos altos

A definição depende da criticidade e da tolerância do negócio.

Estratégias de Disaster Recovery

As estratégias de DR apresentam diferentes relações entre custo e velocidade de recuperação.

Backup and Restore

Os dados e configurações são preservados, mas o ambiente de recuperação não permanece totalmente ativo.

Quando ocorre o desastre:

1. A infraestrutura é recriada.
2. Os dados são restaurados.
3. A aplicação é implantada.
4. O tráfego é redirecionado.

Características

• Menor custo
• Maior tempo de recuperação
• Adequado para sistemas menos críticos
• Dependência de automação para reduzir o RTO

Pilot Light

Uma parte mínima e essencial da solução permanece ativa no ambiente de contingência.

Normalmente, permanecem ativos:

• Dados
• Replicação
• Serviços essenciais
• Configurações básicas

Em um desastre, os demais recursos são iniciados ou ampliados.

Características

• Custo baixo a moderado
• Recuperação mais rápida que Backup and Restore
• Necessidade de automação
• Parte da infraestrutura já preparada

Warm Standby

Uma versão reduzida, mas funcional, permanece ativa.

Ela recebe dados e pode atender uma pequena carga.

Em caso de desastre:

1. O ambiente é escalado.
2. O tráfego é redirecionado.
3. A contingência assume a produção.

Características

• RTO menor
• Custo maior
• Ambiente continuamente funcional
• Necessidade de testes frequentes

Hot Standby

No Hot Standby, ou Active-Passive, existe um ambiente secundário totalmente provisionado e pronto para assumir.

O ambiente principal recebe o tráfego, enquanto o secundário permanece preparado.

Características

• Recuperação rápida
• Custo elevado
• Duplicação de infraestrutura
• Sincronização contínua
• Failover controlado

Active-Active

Dois ou mais ambientes atendem tráfego simultaneamente.

Caso um deles falhe, os demais continuam operando.

Características

• RTO muito baixo
• Alta disponibilidade
• Custo elevado
• Complexidade de dados e roteamento
• Necessidade de tratar consistência
• Operação significativamente mais complexa

Comparando estratégias de DR

Redundância física

Redundância física evita que todos os componentes dependam do mesmo local, provedor ou recurso.

Ela pode envolver:

• Zonas de disponibilidade diferentes
• Regiões diferentes
• Data centers distintos
• Links de rede diferentes
• Provedores diferentes
• Fontes de energia diferentes
• Serviços externos alternativos

Ter duas instâncias na mesma máquina física não oferece redundância real.

Da mesma maneira, manter o ambiente principal e a contingência no mesmo local pode não proteger contra um desastre regional.

Uso de fornecedores diferentes

Alguns negócios podem exigir mais de um fornecedor para uma mesma capacidade.

Exemplos:

• Dois provedores de pagamento
• Dois serviços de telecomunicação
• Duas regiões
• Duas clouds
• Dois canais de envio de mensagens

Isso reduz dependência, mas aumenta:

• Integrações
• Testes
• Governança
• Custos
• Complexidade operacional

A separação geográfica necessária deve ser determinada pelo risco e pelas regras aplicáveis.

Uma distância específica não deve ser tratada como regra universal sem validação na regulamentação ou política correspondente.

Testes como parte da resiliência

Resiliência não pode existir apenas no desenho arquitetural.

Ela precisa ser verificada.

Testes unitários

Validam a menor unidade de comportamento.

Podem proteger:

• Regras de negócio
• Tratamento de erros
• Comportamentos de fallback
• Idempotência
• Validações
• Transições de estado

Testes unitários não comprovam a resiliência do sistema inteiro, mas protegem seus componentes fundamentais.

Testes de integração

Validam a comunicação entre componentes reais ou equivalentes.

Exemplos:

• Aplicação e banco de dados
• Serviço e fila
• API e provedor externo
• Produtor e broker

Testes de contrato

Verificam se produtor e consumidor respeitam o contrato estabelecido.

Podem validar:

• Campos obrigatórios
• Tipos
• Formatos
• Códigos de resposta
• Eventos
• Compatibilidade entre versões

Testes end-to-end

Validam um fluxo completo.

Exemplo

Cliente cria pedido
↓
Pagamento é processado
↓
Estoque é atualizado
↓
Nota fiscal é gerada

Eles são importantes, mas costumam ser:

• Mais lentos
• Mais caros
• Mais frágeis
• Mais difíceis de diagnosticar

Por isso, não substituem testes unitários, de integração ou de contrato.

Chaos Engineering

Chaos Engineering testa a capacidade de o sistema responder a falhas controladas.

Em vez de esperar um desastre real, a organização introduz falhas deliberadamente para verificar se as estratégias funcionam.

Exemplos

• Derrubar uma instância
• Aumentar a latência
• Interromper uma dependência
• Limitar CPU
• Simular perda de rede
• Tornar uma zona indisponível
• Interromper acesso ao banco
• Produzir mensagens duplicadas

O objetivo não é quebrar o sistema aleatoriamente.

Um experimento precisa possuir:

• Hipótese
• Escopo controlado
• Métricas
• Critérios de interrupção
• Responsáveis
• Plano de reversão
• Observabilidade

Exemplo de hipótese

Chaos Monkey

Chaos Monkey é uma ferramenta criada pela Netflix para desligar instâncias de forma controlada.

A finalidade é verificar se o sistema continua funcionando quando parte da infraestrutura falha.

O aprendizado central é:

Os testes devem começar em ambientes controlados e evoluir conforme a maturidade da organização.

Dependências externas e Zero Trust

Serviços externos podem:

• Ficar indisponíveis
• Mudar contratos
• Responder lentamente
• Sofrer incidentes
• Retornar dados incorretos
• Ser comprometidos

Nenhum componente externo deve ser considerado infalível ou automaticamente confiável.

Essa visão se conecta ao Zero Trust.

Zero Trust

Zero Trust parte do princípio de que nenhum usuário, dispositivo ou serviço deve receber confiança automática.

Princípios

• Verificar explicitamente
• Aplicar menor privilégio
• Assumir que uma violação pode existir
• Registrar e monitorar acessos
• Limitar o raio de impacto

Aplicação prática

• Toda chamada entre serviços deve ser autenticada
• Permissões devem ser mínimas
• Credenciais devem possuir prazo e escopo
• Ações sensíveis devem ser auditadas
• Redes internas também precisam de proteção
• Comportamentos anormais devem ser monitorados

Gestão de segredos

Senhas, tokens, certificados e chaves não devem ser armazenados diretamente:

• No código
• Em repositórios Git
• Em arquivos compartilhados
• Em imagens de contêiner
• Em logs
• Em documentos sem controle

Ferramentas especializadas podem gerenciar:

• Segredos
• Chaves criptográficas
• Certificados
• Credenciais temporárias
• Rotação
• Políticas de acesso
• Auditoria

O princípio mais importante é centralizar e controlar os segredos, evitando sua distribuição sem governança.

LGPD e privacidade

LGPD significa Lei Geral de Proteção de Dados Pessoais.

A arquitetura precisa incorporar privacidade desde o desenho.

Dados sensíveis em logs

Informações como estas não devem aparecer indiscriminadamente:

• CPF
• Senhas
• Tokens
• Cartões
• Dados de saúde
• Endereços
• Dados bancários

Possíveis controles:

• Mascaramento
• Tokenização
• Criptografia
• Redação de campos
• Políticas de retenção
• Controle de acesso

Direitos do titular e retenção

A arquitetura pode precisar apoiar, conforme a base legal e o contexto:

• Consulta dos dados
• Correção
• Portabilidade
• Revogação de consentimento
• Anonimização
• Eliminação quando aplicável

Excluir dados não significa necessariamente apagar indiscriminadamente todos os registros.

O sistema precisa diferenciar:

• Dados que podem ser eliminados
• Dados que precisam ser anonimizados
• Dados sujeitos a retenção obrigatória
• Registros necessários para auditoria

Gestão de Mudanças

Gestão de Mudanças, ou GMUD, estabelece controle sobre alterações realizadas em sistemas e ambientes.

Ela deve permitir responder:

• O que foi alterado?
• Quem realizou a alteração?
• Quando ocorreu?
• Quem aprovou?
• Qual era o risco?
• Como foi testado?
• Qual era o plano de rollback?
• Qual foi o resultado?

O objetivo não é criar burocracia sem propósito.

É reduzir alterações improvisadas, sem teste ou sem rastreabilidade.

CI/CD e governança de entrega

Pipelines de integração e entrega contínuas ajudam a tornar mudanças:

• Repetíveis
• Auditáveis
• Testáveis
• Rastreáveis
• Reversíveis

Um pipeline pode conter:

Compilação
↓
Testes unitários
↓
Testes de integração
↓
Análise de qualidade
↓
SAST
↓
Verificação de dependências
↓
Construção do artefato
↓
Assinatura
↓
Deploy
↓
Testes pós-implantação
↓
Monitoramento
↓
Rollback, se necessário

SAST

SAST significa Static Application Security Testing.

Ele analisa o código ou artefato sem executar a aplicação.

Pode identificar:

• Padrões inseguros
• Uso inadequado de APIs
• Fluxos de dados vulneráveis
• Problemas de validação
• Possíveis falhas de segurança

DAST

DAST significa Dynamic Application Security Testing.

Ele testa a aplicação em execução.

Pode identificar:

• Falhas de autenticação
• Configurações inseguras
• Vulnerabilidades expostas
• Comportamentos indevidos
• Problemas nas interfaces reais

Feature Flags

Feature Flags permitem ativar ou desativar funcionalidades sem realizar um novo deploy.

Elas podem ser utilizadas para:

• Liberar funcionalidades para usuários específicos
• Testar uma funcionalidade
• Interromper rapidamente um recurso
• Realizar experimentos
• Separar deploy de release

Cuidado

Flags antigas precisam ser removidas.

Caso contrário, acumulam complexidade e criam múltiplos caminhos difíceis de testar.

Progressive Delivery

Progressive Delivery libera uma nova versão gradualmente.

Exemplo:

1% dos usuários
↓
5%
↓
20%
↓
50%
↓
100%

A progressão depende das métricas observadas.

Canary Release

Uma pequena parcela do tráfego utiliza a nova versão.

Caso os indicadores permaneçam saudáveis, a liberação aumenta.

Métricas possíveis:

• Taxa de erro
• Latência
• Uso de recursos
• Conversão
• Cancelamentos
• Incidentes

Blue-Green Deployment

Dois ambientes completos são mantidos:

• Blue: versão atual
• Green: nova versão

Após a validação, o tráfego é direcionado para o novo ambiente.

Tráfego → Blue
 
Validação do Green
 
Tráfego → Green

A estratégia pode facilitar a reversão do tráfego, mas aumenta o custo de manter dois ambientes.

Rollback

Rollback permite retornar à versão anterior.

Para ser confiável, precisa considerar:

• Aplicação
• Banco de dados
• Contratos
• Mensagens
• Configurações
• Migrações
• Compatibilidade

Documentação arquitetural com C4

O modelo C4 documenta a arquitetura em quatro níveis:

1. Contexto
2. Contêineres
3. Componentes
4. Código

Seu valor está em permitir explicações adequadas para públicos diferentes.

Uma liderança pode precisar da visão de contexto.

Um desenvolvedor pode precisar da visão de componentes.

Architecture Decision Record

ADR significa Architecture Decision Record.

Um ADR registra uma decisão arquitetural.

Ele pode conter:

• Contexto
• Problema
• Alternativas
• Decisão
• Consequências
• Responsáveis
• Data
• Status

Exemplo

Decisão:
Adotar comunicação assíncrona para emissão de nota fiscal.
 
Motivo:
A emissão depende de um serviço externo e não deve bloquear a confirmação do pedido.
 
Consequências positivas:
- Menor tempo de resposta
- Maior resiliência
- Possibilidade de reprocessamento
 
Consequências negativas:
- Consistência eventual
- Necessidade de monitorar filas
- Maior complexidade operacional

O ADR não existe apenas para comprovar quem aprovou.

Seu valor está em preservar o contexto para decisões e revisões futuras.

Auditorias e regulamentação

Empresas podem estar sujeitas a:

• Normas ISO
• Relatórios e controles SOC
• Regras do Banco Central
• Regulamentações da SUSEP
• LGPD
• Políticas internas
• Normas setoriais

Auditorias precisam de evidências verificáveis.

Exemplos de evidências

• Logs
• Aprovações
• Resultados de testes
• Histórico de deploy
• Relatórios de backup e restore
• Controle de acessos
• ADRs
• Registros de mudanças
• Evidências de recuperação

Complexidade e criticidade do negócio

Todas as estratégias descritas aumentam a complexidade.

Implementar:

• Active-Active
• Circuit Breaker
• Filas
• Replicação
• Chaos Engineering
• Multi-cloud
• Gestão avançada de segredos
• Progressive Delivery

pode melhorar a resiliência.

Também pode aumentar:

• Custos
• Operação
• Monitoramento
• Quantidade de falhas possíveis
• Necessidade de especialistas
• Tempo de desenvolvimento

Por isso, a criticidade do negócio precisa orientar a decisão.

Perguntas necessárias

• Quanto custa uma hora de indisponibilidade?
• Quanto dado pode ser perdido?
• Qual é o impacto para o cliente?
• Existe risco regulatório?
• O time consegue operar a solução?
• O ganho justifica o custo?
• Precisamos disso agora?
• Uma alternativa mais simples atende?

Como comunicar trade-offs

Uma decisão arquitetural madura deve declarar:

E também:

Exemplo: Disaster Recovery

Exemplo: Retry

Correções terminológicas importantes

Checklist de resiliência e governança

Antes de concluir uma decisão, avalie:

Dependências

• Todas as chamadas possuem timeout?
• Quais falhas podem receber retry?
• Existe backoff e jitter?
• Os retries estão coordenados?
• É necessário Circuit Breaker?
• Os recursos precisam de isolamento?

Consistência

• A operação é idempotente?
• Mensagens podem ser duplicadas?
• Existe chave de idempotência?
• Como reprocessamentos são controlados?

Continuidade

• Qual é o RPO?
• Qual é o RTO?
• O backup já foi restaurado?
• Existe estratégia de DR?
• O failover é testado?
• Quem ativa a contingência?

Segurança

• Os acessos seguem menor privilégio?
• Chamadas internas são autenticadas?
• Segredos possuem rotação?
• Logs evitam dados sensíveis?
• Ações críticas são auditadas?

Entrega

• O pipeline executa testes?
• Existem verificações de segurança?
• O rollout é gradual?
• O rollback foi planejado?
• Migrações são compatíveis?

Governança

• A decisão está registrada em ADR?
• A mudança possui rastreabilidade?
• Existem evidências para auditoria?
• O custo da solução é conhecido?
• O time consegue operar a arquitetura?

Conclusão

Arquiteturas confiáveis são construídas assumindo que falhas acontecerão.

Timeout impede esperas ilimitadas.

Retry trata falhas transitórias, mas pode amplificar sobrecargas.

Circuit Breaker interrompe chamadas para dependências instáveis.

Bulkhead isola recursos e reduz o raio de impacto.

Fallback mantém parte da experiência disponível.

Idempotência evita efeitos duplicados.

Entretanto, resiliência não termina nesses padrões.

Uma estratégia completa também precisa considerar três frentes:

Continuidade: backups restauráveis, Disaster Recovery, RPO, RTO e testes.

Prevenção e aprendizado: Chaos Engineering, segurança e privacidade.

Controle de mudança: governança, pipelines, estratégias de release, documentação e evidências de auditoria.

Cada nível adicional de proteção produz custos e complexidade.

Por isso, uma arquitetura resiliente não é aquela que promete nunca falhar.

É aquela que conhece seus limites, contém seus problemas, recupera-se dentro do prazo exigido e torna explícito o preço de cada decisão.