Quando uma fila resolve mais do que um retry
Uma integração falhava 3 vezes por dia num sistema que tentava retry síncrono com timeout crescente. A solução não era tentar mais — era desacoplar.
O problema
O sistema chamava uma API externa de forma síncrona durante o processamento de pedidos. Quando essa API demorava ou falhava, o retry aumentava o timeout: 5s, 10s, 30s. A API do nosso sistema ficava travada esperando, e o tempo de resposta subia para 12 segundos no pior caso. Três falhas diárias significavam impacto direto na operação.
O diagnóstico
O retry síncrono criava dois problemas: o chamador ficava bloqueado esperando, e a falha era silenciosa — quando o timeout estourava, só tínhamos um log genérico "timeout exception". Não havia como saber se a falha era temporária, se o payload era inválido, ou se a API externa estava fora.
A solução: RabbitMQ + dead-letter
Troquei a chamada síncrona por uma publicação em fila. O fluxo ficou:
- O endpoint recebe o pedido e publica na fila principal — responde em ~200ms
- Um consumer processa a mensagem e chama a API externa
- Se falha, a mensagem vai para a dead-letter queue com metadados (tentativa, erro, timestamp)
- Um segundo consumer reprocessa a dead-letter com backoff exponencial
O resultado
Tempo de resposta da API caiu de 12s para 200ms. As falhas deixaram de ser invisíveis — cada mensagem na dead-letter tinha contexto completo. O time de operações passou a monitorar a fila e agir antes de virar incidente.
O aprendizado
Nem todo problema de integração precisa de mais tentativas. Às vezes o que falta é desacoplamento: deixar o chamador seguir em frente e tratar a falha de forma assíncrona, com contexto suficiente para agir. A fila não é overhead — é a separação correta de responsabilidades.