Identificar o efeito prometido
Numa integração fictícia de reconciliação, receber a mensagem não significa concluir o lançamento. Regista a operação lógica que o consumidor pretende executar e como pode reconhecer uma repetição. Uma falha depois do efeito, mas antes do reconhecimento, deixa um resultado incerto para o componente que recebe novamente. A fila não coordena automaticamente uma transação com o sistema externo. Escolhe uma proteção que corresponda à operação, incluindo concorrência e recuperação. Uma chave nova por tentativa pode destruir essa correspondência. Na passagem para RUN, documenta como distinguir trabalho pendente, efeito concluído e resultado ainda por reconciliar, incluindo os sinais que justificam repetir ou investigar.
Calcular a visibilidade a partir da alteração
O visibility timeout oferece tempo para processar e reconhecer, mas não é uma garantia universal contra duplicados. Num exemplo, a receção ocorre em t=0 com 40 segundos de visibilidade. Aos 25 segundos, uma alteração aceite define 60 segundos. O novo prazo é t=85, contado a partir da alteração, não t=100 por soma ao prazo anterior. Este modelo ignora latência de transporte e outras alterações. Na implementação, planeia margem, observa duração real e trata falhas de renovação. Um prazo excessivo também atrasa a recuperação de trabalho abandonado. Não confundas duração de espera por mensagens com visibilidade de uma mensagem já recebida; configuram fases diferentes do percurso.
Delimitar a deduplicação FIFO
A deduplicação de envio FIFO cobre um intervalo de cinco minutos; não deve ser tratada como um histórico permanente dos efeitos de negócio. Se o produtor repete a operação sete minutos depois, essa proteção isolada não resolve a repetição. Quando usas content-based deduplication, o hash considera o corpo e exclui atributos. Duas operações diferentes com corpo igual e identificador apenas num atributo podem colidir nesse mecanismo. Define identidade lógica coerente: operações diferentes têm IDs distintos, enquanto tentativas da mesma operação mantêm o ID adequado. A escolha também deve corresponder à proteção do consumidor. Não concluas que ordenação ou deduplicação de envio demonstra execução única de uma ação financeira externa.
Responder a falhas por registo
Numa integração SQS standard com Lambda, uma falha do lote pode fazer repetir também registos já processados. Com ReportBatchItemFailures ativo e uma resposta válida, o código identifica os message IDs que falharam em batchItemFailures. Não devolve receipt handles nem a lista de sucessos. Se a função lança uma exceção não tratada, o lote é considerado falha completa, apesar da configuração. Uma lista vazia comunica sucesso. Por isso, os testes precisam de observar configuração e resposta, além dos logs. Nos modelos desta aula, compara o conjunto que devia ser repetido com o conjunto realmente devolvido e inclui casos de erro que ocorrem depois de parte do trabalho ter concluído.
Preservar a ordem necessária
A fronteira de ordenação deve corresponder ao negócio. Se só precisas de ordem por conta, um MessageGroupId estável por conta permite independência entre grupos. Usar global para tudo cria uma fronteira de serialização mais ampla. Aumentar consumidores não elimina essa fronteira. Dentro de um lote FIFO do mesmo grupo, se A conclui, B falha e C está por executar, interrompe o processamento após B e devolve B e C como falhada e não processada. Executar C antecipadamente pode produzir efeitos numa ordem diferente. Avalia também a utilização de DLQ: retirar uma mensagem problemática pode quebrar a sequência exata pretendida. Documenta como a aplicação trata essa lacuna antes de permitir continuação.
Preparar recuperação e evidência
Uma DLQ precisa de dono, retenção, alarmes e procedimento de análise. Em filas standard, a passagem para DLQ mantém o timestamp original para expiração. Se uma mensagem chega após três dias e a retenção da DLQ é seis, restam aproximadamente três dias, sem outras operações. FIFO tem comportamento diferente, com reinício do timestamp nessa passagem. Antes de redrive, confirma a causa, a validade dos dados e a capacidade disponível. Preserva a identidade lógica para reconciliar efeitos incertos. Começa com ritmo controlado e observa resultados e falhas. Guardar mensagens numa DLQ não equivale a concluir o trabalho nem garante recuperação depois de expirar a retenção.
A, B e C pertencem ao mesmo grupo FIFO. Se B falha após A concluir, a resposta parcial inclui B e C; C continua por executar.
Armadilhas comuns
Somar a renovação ao prazo antigo, deduplicar só por atributos, devolver sucessos como falhas ou adiantar operações do mesmo grupo.
Tópicos relacionados: Eventos e desacoplamento · Identidade e permissões
Entrega, deduplicação, ordenação e efeito de negócio têm fronteiras diferentes que o desenho precisa de ligar explicitamente.
Referência: Lambda SQS partial batch responses · SAA-C03