Sistema distribuído falha. A pergunta útil não é se vai falhar. É o que acontece quando falha.
Os Blocos Fundamentais de Resiliência
- Timeout: Corta espera infinita. Sem ele, uma chamada travada segura thread, conexão e, em cascata, o restante do fluxo.
- Retry com Backoff e Jitter: Trata falha transitória (rede instável, serviço reiniciando). Sem jitter, vários clientes retentam juntos e pioram o problema.
- Circuit Breaker: Para de martelar o que já está caindo. Depois de N falhas, abre. As próximas chamadas falham rápido, sem consumir recurso. Depois de um tempo, testa de novo.
- Bulkhead: Isola pool de threads ou conexões por dependência. Uma integração lenta não engole o resto.
- Rate Limiting e Load Shedding: Protegem o lado que recebe. Um corta excesso de chamadas; o outro descarta o que tem prioridade baixa quando a carga passa do limite.
- Deadline Propagation: Carrega o tempo restante entre serviços. Evita trabalho zumbi (processar algo cujo cliente já desistiu).
Arquiteturas e Paradigmas
Microsserviços
Em microsserviços, muita coisa saiu do código e foi para a malha. Service mesh (Istio, Linkerd, Envoy) configura retry, timeout e circuit breaker em YAML. Sidecar cuida disso ao lado de cada serviço. Para transações distribuídas, Saga (orquestrada ou coreografada) evita two-phase commit. Outbox garante que o evento saia depois da escrita no banco. Idempotency keys tornam o retry seguro em pagamento e pedido.
Serverless
Serverless muda o desenho. Função pode ser reexecutada pelo provedor, tornando a idempotência obrigatória. Exige timeout curto por função e DLQ para isolar o que falha repetidamente. Step Functions (ou Durable Functions) orquestram etapas com retry nativo.
Frontend
No frontend, o mesmo raciocínio aparece em outra forma: retry no client, circuit breaker para não bombardear API já fora, cache com stale-while-revalidate, Optimistic UI com rollback, Error Boundary para isolar componente sem derrubar a tela inteira e estratégia offline-first com fila de ações.
Banco de Dados e Mensageria
Possuem seu próprio conjunto: connection pool com limite (bulkhead de fato), read replica com failover, DLQ, schema registry e consumer com backoff.
Observabilidade
Observabilidade não é detalhe. Tracing distribuído mostra onde a falha começou. SLO e error budget dizem quanto de confiabilidade o time pode "gastar" em troca de velocidade. Sem isso, as técnicas acima viram configuração no escuro.
Resumo Prático por Camada
- Frontend sozinho: Retry, cache local, error boundary, offline-first.
- Vários clientes + API instável: BFF/Gateway centralizando circuit breaker, retry e cache.
- Microsserviços: Mesh + Saga + Outbox + Bulkhead + DLQ.
- Serverless: Idempotência + DLQ + timeout curto.
- Banco de dados: Pool, replica, failover.
O Ponto Central
Resiliência não é lista de libs. É decidir, por camada, o que falha isolado e o que propaga.
Quanto mais o código é gerado por agentes, mais essa decisão precisa estar explícita no contexto e na arquitetura — senão o sistema ganha velocidade e perde capacidade de sobreviver à falha.
📚 Artigo Completo e Leituras Recomendadas
Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa no meu blog.
Quem quiser aprofundar arquitetura e design de soluções na era da IA encontra o tema tratado de forma estruturada no Volume IV da série Engenharia de Software Assistida por IA.
💡 Destaques:
- 🏷️ Cupom de 30% OFF nos eBooks:
LEIA30 - 📖 Disponível também no Kindle Unlimited!
📖 Livros Físicos (capa comum):
- 📘 Volume I - A Nova Realidade da Engenharia de Software
- 📙 Volume II - Fundamentos que a IA Não Substitui
- 📗 Volume III - Engenharia de Requisitos na Era da IA
- 📕 Volume IV - Arquitetura e Design de Soluções na Era da IA
- 📓 Volume V - Delegação Técnica para IA
- 📔 Volume VI - Supervisão e Auditoria de Código Gerado por IA
- 📒 Volume VII - Aplicações Reais
- 📗 Volume VIII - Engenharia de Contexto e Governança de IA
#SoftwareEngineer #Resilience #SoftwareArchitecture #Microservices #AI #Csharp #Typescript #DotNet #Java #Javascript #DevOps
Top comments (0)