Confiabilidade em sistemas distribuídos: oito padrões para recuperar falhas

TL;DR

Um sistema distribuído coordena trabalho entre processos que se comunicam por uma rede. Uma parte pode falhar enquanto as outras continuam funcionando. Confiabilidade significa preservar comportamentos úteis e recuperar o funcionamento de forma previsível quando essas falhas parciais acontecem.

• Limite espera e repetição com timeouts, orçamentos de retentativa e circuit breakers.
• Contenha a sobrecarga com recursos separados, filas limitadas e backpressure.
• Proteja efeitos com idempotência, inspecione falhas e meça o resultado para o usuário.

Vamos acompanhar o pedido fictício ORDER-42: aceitá-lo, solicitar o pagamento, salvar seu estado e enviar uma confirmação por email. A chave K42 identifica uma intenção de pagamento. Todos os números são hipóteses didáticas, não configurações recomendadas para produção. Os oito padrões tratam riscos diferentes; mesmo combinados, precisam de estado durável, responsabilidades claras e um procedimento de recuperação exercitado.

1. Timeouts: limitar a espera

Sem timeout, o serviço de pedidos pode esperar indefinidamente pelo pagamento, mantendo conexão e memória ocupadas. O timeout limita essa espera. Escolha limites com base na latência observada e no prazo da jornada do usuário, incluindo abertura de conexão e leitura da resposta.

Diferencie o timeout de uma tentativa do prazo total: três tentativas e seus intervalos não podem gastar, cada um, todo o orçamento da requisição. Propague o tempo restante e cancele o trabalho quando houver suporte. O cancelamento depende da cooperação entre componentes; a cobrança remota pode já ter sido confirmada. Timeout deixa um resultado desconhecido, não comprova falha. A Amazon explica a relação entre escolha de timeouts e retentativas.

2. Retentativas: repetir com um orçamento

Uma retentativa pode ajudar depois de uma interrupção breve da rede. Ela não corrige um cartão inválido ou a falta de permissão. Classifique os erros, confira se repetir é seguro e pare ao atingir o limite de tentativas ou o prazo total. Respeite a orientação do provedor sobre novas chamadas.

Backoff exponencial aumenta o intervalo entre tentativas; jitter acrescenta variação aleatória para que os clientes não voltem todos juntos. Por exemplo, sorteie a espera entre zero e um limite crescente com teto. Isso distribui carga, mas não garante recuperação. Defina um responsável pelas retentativas: três tentativas totais em cada uma de três camadas aninhadas podem gerar 27 tentativas na dependência final.

3. Circuit breakers: dar tempo à dependência

Se o pagamento continua falhando, insistir a cada novo pedido acrescenta pressão. Um circuit breaker, ou disjuntor, usa resultados recentes para interromper temporariamente as chamadas à dependência. Fechado permite tráfego normal; aberto recusa chamadas rapidamente; semiaberto permite uma sondagem limitada de recuperação. O sucesso fecha o circuito; uma sondagem malsucedida volta a abri-lo.

Defina janela de observação, volume mínimo, falhas relevantes e limites das sondagens. Uma recusa de negócio não deve contar automaticamente como indisponibilidade da infraestrutura. Mantenha o pedido visivelmente pendente ou apresente uma recusa clara; nunca use um pagamento fictício como alternativa. O disjuntor observa sintomas, não a saúde definitiva de um serviço inteiro. A Microsoft documenta as transições e os cuidados com a recuperação.

4. Bulkheads: conter o esgotamento de recursos

Um provedor de email com problemas não deveria ocupar todas as conexões necessárias para aceitar pedidos. Bulkheads, nome inspirado nas divisórias de navios, separam orçamentos de recursos: reserve um grupo de workers para pedidos e outro para email, cada um com concorrência limitada. Workers são processos que executam tarefas; um pool é um grupo limitado de recursos reservado para uma carga de trabalho.

A separação custa capacidade ociosa e configuração adicional. Também possui um limite: grupos distintos que compartilham um banco ou servidor esgotado ainda podem falhar juntos. Identifique os recursos compartilhados e limite o gargalo real, considerando a carga agregada de todas as réplicas. O padrão bulkhead da Microsoft descreve o isolamento e suas contrapartidas.

5. Backpressure: respeitar a capacidade

Imagine que chegam 100 pedidos por segundo, mas os workers concluem 60. O acúmulo cresce aproximadamente 40 por segundo até o tráfego ou a capacidade mudar. Uma fila absorve um pico; ela não resolve um déficit contínuo de capacidade. Limite seu tamanho, o tempo de espera e a taxa de processamento dos consumidores.

Backpressure comunica a capacidade limitada a quem produz o trabalho: pausar a entrada, reduzir a concorrência dos produtores ou recusar explicitamente. Use uma resposta adequada, como HTTP 429 para o limite de chamadas de um cliente ou 503 para indisponibilidade temporária, com orientação para tentar novamente quando útil. HTTP é o protocolo de comunicação usado nessas requisições. Uma requisição descartada não é trabalho aceito. Aceitação durável exige registro salvo e caminho de recuperação até o processamento. A Microsoft explica o amortecimento por filas, a espera crescente e os limites das dependências.

6. Idempotência: proteger o efeito de negócio

Idempotência significa que repetir a mesma operação lógica não cria outro efeito de negócio pretendido. Se a resposta do pagamento desaparecer, repita a intenção com K42, sem gerar outra identidade. O servidor pode devolver o resultado salvo.

Restrinja a chave ao responsável e à operação, vincule-a aos dados da requisição e recuse seu reaproveitamento com outra intenção. Proteja tentativas concorrentes com restrições duráveis ou transições atômicas; uma sequência de “consultar e depois inserir” permite disputas. Especifique por quanto tempo as chaves são mantidas e o que acontece após expirarem. A Amazon discute identidade, retentativas tardias e mudança de intenção.

7. Dead-letter queues: recuperar com critério

Uma mensagem de confirmação malformada pode falhar toda vez que um worker a recebe. Após uma política definida de tentativas de entrega, separe-a para que outros trabalhos avancem. Uma dead-letter queue (DLQ), ou fila de mensagens não processadas com sucesso, guarda esses itens para investigação e possível reprocessamento; não os corrige.

Defina responsável, alertas e retenção. Registre um motivo sanitizado, corrija a causa e reprocese aos poucos com a identidade original da operação. Reenviar tudo de uma vez pode recriar a sobrecarga. Retirar uma mensagem de um fluxo ordenado também pode violar a ordem necessária ao negócio. O Amazon SQS documenta inspeção, reenvio e limitações de ordenação.

8. Observabilidade: explicar o que aconteceu

Observabilidade é a capacidade de entender o comportamento interno pelas evidências emitidas. Logs registram eventos, métricas resumem quantidades no tempo e traces conectam etapas de uma requisição entre componentes. Correlacione pedido, pagamento e email sem registrar dados de cartão, credenciais ou informações pessoais desnecessárias. O OpenTelemetry descreve esses sinais complementares. A OWASP orienta a exclusão de dados sensíveis dos logs.

Acompanhe pedidos concluídos, latência, erros e saturação, além do trabalho mais antigo na fila, retentativas por operação, transições do disjuntor e mensagens pendentes de tratamento. Alerte quando alguém precisar agir, com responsável e instruções de recuperação. Telemetria ajuda no diagnóstico; instalar um painel, por si só, não torna falhas previsíveis. O guia de monitoramento do Google conecta sinais e alertas ao comportamento do serviço.

9. Percorrer uma falha antes da produção

O pagamento dá certo, sua resposta desaparece e o email está indisponível. O serviço de pedidos atinge o prazo e mostra um resultado pendente. Uma retentativa limitada ou reconciliação consulta K42 para resolver o pagamento. As falhas de email permanecem no próprio orçamento; mensagens sem solução viram trabalho de recuperação visível, sem bloquear novos pedidos.

Verifique os limites em um ambiente controlado:

• Descarte a resposta após o pagamento; confira quantos efeitos o provedor confirmou.
• Envie cópias concorrentes de K42; inspecione o estado durável e dados conflitantes.
• Mantenha uma dependência indisponível; observe retentativas, circuitos e sondagens.
• Exceda a capacidade; confira memória, idade da fila e recusas explícitas.
• Reprocesse uma mensagem corrigida; confira o resultado e a trilha da ação operacional.

Esses são cenários de verificação, não resultados medidos neste artigo. Comece pela falha que seu fluxo precisa tolerar e escolha o menor mecanismo que a trate. Para entender os requisitos, as responsabilidades e a aceitação durável ao redor desse fluxo, leia o guia de System Design.

Perguntas frequentes

Fontes e próximas leituras

As pesquisas originais que fundamentam o artigo, para quem deseja explorar os detalhes.

1. Timeouts, retries, and backoff with jitter Amazon Builders’ Library
2. Circuit Breaker pattern Microsoft Azure Architecture Center
3. Bulkhead pattern Microsoft Azure Architecture Center
4. Queue-Based Load Leveling pattern Microsoft Azure Architecture Center
5. Making retries safe with idempotent APIs Amazon Builders’ Library
6. Using dead-letter queues in Amazon SQS Amazon SQS Developer Guide
7. Signals OpenTelemetry
8. Monitoring Distributed Systems Google SRE Book
9. Logging Cheat Sheet OWASP