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

> 7 Padrões de Erro Handling em Aplicações Robustas inclui fallbacks, circuit breakers, retries, graceful degradation, bulkheads, timeouts e error boundaries. Esses padrões transformam falhas em experiência controlada, evitando crashes e mantendo usabilidade. Exemplos práticos demonstram como cada padrão lida com cenários específicos, garantindo resiliência e previsibilidade em sistemas de software.

*PosUp · Apps e Software · 17 de julho de 2026 · Patrícia Lemos*

Erro handling em aplicações robustas não é só try/catch. Conheça 7 padrões, de fallbacks a circuit breakers, que transformam falhas em experiência controlada, com exemplos práticos para cada cenário.

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.

---

Fonte (canonical): https://posup.com.br/apps-e-software/7-padroes-de-erro-handling-em-aplicacoes-robustas/