7 Padrões de Erro Handling em Aplicações Robustas

Erro handling em aplicações robustas vai muito além de um bloco try/catch genérico. Quando um serviço externo cai, uma requisição expira ou um dado chega corrompido, o que define a resiliência do sistema não é evitar o erro, mas como ele responde. Abaixo, sete padrões que separam aplicações frágeis das realmente robustas, cada um com um critério objetivo de aplicação.

1. Fallback Pattern

Quando uma chamada falha, o sistema retorna uma resposta padrão, um cache local, um valor default ou uma versão reduzida do dado. O critério para usar: sempre que o serviço externo não for crítico para a execução principal. Exemplo: um microsserviço de recomendação que, ao falhar, retorna os produtos mais vendidos do cache local em vez de exibir uma tela de erro.

2. Circuit Breaker

Isola um serviço que falha repetidamente, evitando que o sistema inteiro degrade por causa de uma única dependência. O padrão abre o circuito depois de N falhas consecutivas (geralmente 3 a 5), redireciona chamadas para um fallback e tenta reabrir após um timeout. Um número não-redondo comum de threshold: 4 falhas em 10 segundos.

3. Retry Pattern com Exponential Backoff

Para falhas transitórias (timeout de rede, lock de banco), repetir a operação com espera crescente entre tentativas, 1s, 2s, 4s, até um máximo de 30s. O erro comum é aplicar retry sem limite, o que sobrecarrega o serviço já instável. O contraponto: nunca usar retry em erros 4xx (como 401 ou 403), que indicam problema permanente.

4. Graceful Degradation

Em vez de exibir um erro genérico, o sistema reduz funcionalidades. Exemplo: um portal de notícias que, se o serviço de imagens cair, mostra apenas o texto, sem quebrar a página. O critério é mapear cada funcionalidade por prioridade de negócio e definir qual nível de falha cada uma tolera.

5. Bulkhead Pattern

Separa recursos (threads, conexões) por serviço ou funcionalidade, evitando que uma falha em um componente consuma todos os recursos do sistema. Um exemplo: alocar no máximo 5 threads para chamadas ao serviço de pagamento, independentemente de quantas requisições cheguem. Se o pagamento falhar, as demais funcionalidades seguem intactas.

6. Timeout Pattern

Define um limite de espera para cada operação. Um número comum: 500ms para chamadas síncronas e 5s para chamadas assíncronas. O erro mais frequente é não definir timeout algum, deixando o usuário esperando indefinidamente. A ressalva: timeout muito curto pode gerar falsos positivos em operações legítimas de longa duração.

7. Idempotency Pattern

Garante que uma operação executada múltiplas vezes (por retry ou duplicação de mensagens) produza o mesmo resultado. O padrão exige um identificador único (idempotency key) em cada requisição. Exemplo: um POST de cobrança que, se repetido com a mesma chave, não gera uma segunda cobrança. Sem isso, retry vira bug.

Qual padrão escolher?

Comece pelo Fallback e pelo Timeout, são os de menor custo e maior retorno imediato. Depois adicione Circuit Breaker para dependências críticas e Idempotency para operações de escrita. A ordem importa: primeiro evita que o erro chegue ao usuário, depois protege o sistema de se afogar nele.

FAQ

O que é erro handling em aplicações?

É o conjunto de práticas e padrões que define como um sistema reage quando algo dá errado, desde uma requisição que falha até um serviço inteiro que cai. O objetivo não é eliminar erros, mas controlar seu impacto no usuário e no sistema.

Quando usar Circuit Breaker em vez de Retry?

Use Circuit Breaker quando o serviço falha repetidamente (mais de 3 falhas consecutivas, por exemplo). Use Retry apenas para falhas transitórias e isoladas. Se o serviço está fora, retry só piora.

O que é Exponential Backoff?

É uma estratégia de retry que aumenta o tempo de espera entre tentativas de forma exponencial, 1s, 2s, 4s, 8s, para não sobrecarregar o serviço que já está instável. Geralmente combinado com um limite máximo de espera (ex.: 30s).

Como implementar Graceful Degradation?

Mapeie todas as funcionalidades por prioridade de negócio. Para cada uma, defina um estado de falha aceitável, por exemplo, sem imagens, sem recomendações, mas com texto. A implementação usa fallbacks locais ou versões reduzidas dos dados.

O que é Bulkhead Pattern?

É um padrão que separa recursos (threads, conexões de banco) por serviço ou funcionalidade. Se um componente falha e consome todos os recursos, os demais não são afetados. O nome vem dos compartimentos estanques de navios.

Erro handling é só para backend?

Não. Frontends também precisam de fallback (dados em cache), graceful degradation (funcionalidade reduzida) e timeout. A diferença é que no frontend o erro é visível ao usuário imediatamente, então o tratamento precisa ser ainda mais cuidadoso.