Sua fila de mensagens garante entrega pelo menos uma vez. O que isso significa para o consumidor que você escreve?

Significa que duplicatas são normais, não excepcionais, então o seu consumidor precisa ser idempotente. Derive uma chave estável da mensagem, registre as chaves processadas na mesma transação do efeito, e trate uma repetição como um no op. Espere também entrega fora de ordem e reentrega após uma queda entre fazer o trabalho e confirmar. Exatamente uma vez de ponta a ponta não existe entre sistemas; o que você tem é pelo menos uma vez mais tratamento idempotente.

Significa que eu vou receber a mesma mensagem duas vezes, normalmente porque o consumidor fez o trabalho e morreu antes de confirmar, então o broker reentrega. Então o consumidor precisa ser seguro de rodar duas vezes com a mesma entrada. Na prática eu pego um id estável da mensagem e, quando gravo o efeito, gravo o id processado na mesma transação de banco, com uma constraint de unicidade. Se o insert conflitar, eu sei que já tratei aquilo e confirmo sem refazer o trabalho. A parte crítica é que o registro de deduplicação e o efeito comitam juntos; se eu gravar separado, existe uma janela em que posso duplicar. Eu também assumo que a ordem não é garantida, então os handlers são escritos para tolerar um update chegando antes do create, normalmente usando a entidade como chave e checando uma versão. Para falhas eu uso retry limitado com backoff exponencial e jitter, depois uma dead letter queue com alerta, porque tentar de novo uma mensagem envenenada para sempre e em silêncio é como uma fila entope durante a noite.