A alternativa que contempla essas exigências é a D: ativar publisher confirms, usar filas duráveis e mensagens persistentes. Essa combinação assegura a confiabilidade da seguinte forma:

• Publisher Confirms: garante que o produtor receba uma confirmação de que o RabbitMQ recebeu e persistiu a mensagem corretamente. Isso evita que o produtor precise reenviar a mensagem por falta de certeza, reduzindo o tráfego desnecessário na rede.
• Filas Duráveis e Mensagens Persistentes: assegura que as mensagens não sejam perdidas mesmo em caso de reinicialização ou falha do broker RabbitMQ.

Portanto, a configuração descrita na letra D é a que melhor equilibra a confiabilidade da entrega com a minimização de custos operacionais, sendo a recomendada para o cenário descrito.

❌ Alternativa A

Usar filas temporárias e desativar ACKs.

• Para que serve: Cenários de dados efêmeros, como logs de depuração ou notificações descartáveis. As filas desaparecem quando o consumidor se desconecta, e mensagens não confirmadas são perdidas ao reiniciar o broker.

❌ Alternativa B

Definir fanout exchanges com filas exclusivas.

• Para que serve: Distribuir uma mensagem para todas as filas vinculadas (broadcast). Filas exclusivas são temporárias e pertencem a uma única conexão. Útil para eventos em tempo real onde cada consumidor recebe cópia idêntica, mas sem garantia de persistência.

❌ Alternativa C

Ativar o modo NACK nos consumidores e usar mensagens transitórias.

Para que serve: NACK (rejeição com requeue) permite devolver mensagens problemáticas para a fila, útil para tratamento de erros temporários. Mensagens transitórias (não persistentes) são armazenadas apenas em memória, ganhando desempenho.

❌ Alternativa E

Habilitar ACKs manuais nos consumidores e desabilitar persistência de mensagens.

Para que serve: ACK manual dá controle ao consumidor para confirmar só após processamento completo. Sem persistência, as mensagens ficam apenas em RAM – ótimo para throughput alto onde perda eventual é aceitável.

Fonte: DeepSeek