APRENDER. PRATICAR. EVOLUIR.Aceitar uma mensagem não é concluir o negócio
Confirmação do publicador e confirmação do consumidor têm funções diferentes. No exemplo RabbitMQ, o broker pode confirmar a aceitação ao publicador antes de um consumidor concluir o trabalho. Para afirmar que uma operação de negócio terminou, define uma evidência funcional, como registo de processamento ou reconciliação. Não confundas “enviei”, “foi aceite” e “foi aplicado”.
Reentrega e idempotência
Se o consumidor aplica uma operação e falha antes de confirmar, a mensagem pode ser entregue novamente. Uma operação idempotente suporta repetição sem repetir indevidamente o efeito. Isso pode exigir uma chave de negócio e registo transacional de processamento. “A mensagem tem ID” não é suficiente se o consumidor não o usa para controlar duplicações. Analisa também ordenação e o que acontece em falhas parciais.
Profundidade, idade e recuperação controlada
Uma fila grande pode ser normal durante um pico; a idade da mensagem mais antiga e as taxas de entrada/saída ajudam a avaliar atraso. Se a saída é inferior à entrada, o atraso cresce. Distingue ausência de consumidores, consumidores lentos e mensagens que falham repetidamente. Uma fila de erro precisa de triagem, causa corrigida e repetição controlada. Reenviar tudo sem deduplicação pode agravar o incidente.
Aplicação no trabalho
Num consumidor fictício de instruções financeiras, separa aceite pelo broker, entregue ao consumidor e efeito registado. Se o processo falhar depois do efeito e antes do ack, a recuperação pode voltar a entregar a mensagem. Usa a identidade de negócio e o contrato de idempotência para decidir. Observa ready, unacked, idade e taxas; uma fila ready vazia não prova ausência de trabalho em curso.
O consumidor registou uma instrução de pagamento e caiu antes do ack. Na recuperação, a mensagem reaparece. A equipa deve consultar a chave de negócio e a evidência de aplicação antes de repetir o efeito; a presença na fila não prova ausência de processamento anterior.
Armadilhas comuns
Confundir confirm com conclusão de negócio; reenviar sem controlo de efeitos.
Tópicos relacionados: Lançar, observar e recuperar middleware · Retries, idempotência e limites
Entrega e aplicação são eventos diferentes; uma recuperação segura considera repetição e reconciliação.
Referência: Consumer acknowledgements and publisher confirms · DR Middleware 2026.4; HotSpot JDK 25; JDBC 25; PostgreSQL 18; RabbitMQ 4.3; OpenSSL 3.5; explicitly scoped runtime references