Como uma mensagem chega ao consumidor?
O produtor publica em uma exchange com uma routing key. A exchange avalia suas regras de binding e encaminha a mensagem a zero ou mais filas. O consumidor lê de uma fila e confirma (acknowledges) o processamento. Exchange, fila e binding têm papéis distintos; publicar numa exchange não garante por si só que alguma fila recebeu a mensagem.
Direct exchanges roteiam por correspondência de chave; topic exchanges permitem padrões; fanout distribui para filas vinculadas sem considerar chave; headers usa cabeçalhos. Escolha pelo padrão de roteamento necessário, não apenas pelo nome.
Durabilidade, confirmações e reentrega
Para reduzir risco de perda, configure exchanges e filas duráveis quando apropriado, publique mensagens persistentes e use publisher confirms para saber que o broker aceitou a publicação. São proteções diferentes e dependem da configuração de filas, replicação e implantação.
Consumers devem usar ack manual depois de concluir o efeito. Se o processo cair antes do ack, a mensagem pode ser entregue novamente. Se confirmar antes de persistir o resultado, pode perder o trabalho. Esse intervalo torna idempotência importante: grave a chave da mensagem ou use uma operação de negócio naturalmente idempotente.
Backpressure, retries e dead-letter
Prefetch limita quantas mensagens não confirmadas ficam com um consumidor, ajudando a controlar concorrência e memória. Mensagens que falham precisam de uma política: requeue imediato pode criar um ciclo quente que sobrecarrega broker e aplicação. Atrasos, tentativas limitadas e dead-letter exchanges permitem separar falhas transitórias de mensagens que precisam de investigação.
Uma fila dead-letter não é uma lixeira para esquecer. Monitore volume e idade, preserve contexto suficiente para diagnóstico e defina processo seguro de reprocessamento. Evite retry infinito e não descarte a mensagem silenciosamente.
Quando RabbitMQ é uma boa escolha?
É uma opção natural para filas de trabalho, roteamento flexível, distribuição de tarefas e integração assíncrona entre aplicações. Recursos como filas quorum e políticas de alta disponibilidade têm implicações operacionais e devem ser avaliados para a versão e topologia escolhidas.
Se a necessidade principal é reter grandes fluxos de eventos e permitir que vários grupos façam replay em seus offsets, compare com Kafka. Para um serviço gerenciado integrado ao ecossistema Azure, avalie Azure Service Bus. Não há um broker universalmente melhor.
Confiabilidade na aplicação
Broker não torna publicação e gravação no banco atomicamente consistentes. A aplicação que registra um pedido e emite evento pode usar Transactional Outbox, e cada consumidor precisa considerar duplicatas. Configure timeouts, retries com backoff e limites de concorrência: veja resiliência em sistemas distribuídos.
O que monitorar
Acompanhe profundidade e idade das filas, taxa de publicação e consumo, mensagens não confirmadas, redeliveries, conexões e dead-letter. Métricas do broker não explicam sozinhas se uma operação de negócio concluiu; correlacione identificadores de mensagem e traces com cuidado. Veja observabilidade.