Como você projeta um consumidor para uma fila que garante entrega pelo menos uma vez?

Assuma que toda mensagem pode chegar mais de uma vez e torne o processamento idempotente. Derive uma chave estável da mensagem e ou verifique e registre em um armazenamento antes de agir, ou use uma escrita condicional para uma repetição virar operação nula. Defina o visibility timeout acima do seu pior caso de tempo de processamento, estenda para jobs longos, e mande mensagens para uma dead letter queue depois de algumas falhas, para mensagens envenenadas não travarem o progresso.

Eu parto do princípio de que toda mensagem vai chegar pelo menos duas vezes em algum momento, normalmente porque um consumidor foi lento e o visibility timeout expirou enquanto o trabalho já tinha sido commitado. Então o consumidor tem que ser idempotente, e eu quero isso concreto em vez de aspiracional. Normalmente é uma chave de idempotência tirada da mensagem, ou um id que o produtor definiu ou um hash do conteúdo relevante, registrada em uma tabela com uma restrição de unicidade dentro da mesma transação do trabalho. Se o insert conflita, a gente já fez isso, confirma e segue. Onde o efeito é uma escrita em um armazenamento, eu prefiro uma atualização condicional, para aplicar duas vezes chegar no mesmo estado. Operacionalmente, o visibility timeout tem que exceder o tempo de processamento realista mais lento, e para jobs genuinamente longos eu estendo a concessão conforme avanço em vez de definir um timeout global enorme. As falhas fazem retry com backoff exponencial e jitter, e depois de um número pequeno de tentativas a mensagem vai para uma dead letter queue com o erro anexado, para uma mensagem ruim nunca travar o resto.