Visibility Timeout e Exclusão no SQS

Definição

Visibility timeout é o período em que uma mensagem recebida fica temporariamente invisível para novas solicitações. Ela continua na fila. Ao terminar o processamento, o consumidor deve excluí-la; se não excluir antes do timeout, ela pode ser recebida novamente.

ChangeMessageVisibility ajusta o prazo de uma entrega. Isso permite prolongar o processamento ou antecipar uma nova tentativa. A invisibilidade não deve ser tratada como um bloqueio distribuído absoluto: filas Standard continuam tendo semântica de entrega pelo menos uma vez. Referência: visibility timeout.

Exemplo de falha

00 s: worker A recebe a mensagem; timeout de 30 segundos
20 s: A grava o resultado no banco
21 s: A cai antes de excluir a mensagem
30 s: a mensagem pode ser recebida pelo worker B

B precisa reconhecer que aquele evento já produziu seu efeito. Um registro único do identificador, gravado na mesma transação que o resultado, pode proteger esse caso. Uma marca gravada antes do resultado ou em operação separada cria outras janelas de falha.

Receipt handle

Cada recebimento fornece um receipt handle, identificador daquela entrega. DeleteMessage usa esse handle, não o MessageId. Em uma nova entrega, o handle muda; a exclusão deve usar o mais recente. Referência: DeleteMessage.

mensagem = ReceiveMessage(fila)
processar_com_idempotencia(mensagem.corpo)
DeleteMessage(fila, mensagem.receipt_handle)

O exemplo representa o fluxo lógico. Na integração real, falhas de processamento e de exclusão também precisam ser tratadas. Excluir antes de persistir o resultado pode fazer o trabalho desaparecer quando o consumidor cai.

Três tempos diferentes

Um timeout curto favorece reentrega durante trabalho ainda em andamento. Um timeout longo aumenta a demora para recuperar trabalho de um consumidor que caiu.

Aprofundamento aplicado

Renovar a entrega não substitui detectar consumidor parado

Um trabalho de duração variável pode renovar visibilidade antes do vencimento. O worker precisa interromper a renovação quando falha ou perde condições de concluir; prolongar indefinidamente uma tarefa travada impede recuperação rápida.

A renovação também pode falhar por rede ou por handle inválido. Nesse caso, o worker não deve presumir posse exclusiva: outro consumidor pode receber a mensagem. A proteção do efeito deve estar no destino, por idempotência ou condição adequada. Referência: ajuste de visibilidade.

Exercício: use uma tarefa de 45 s e visibilidade inicial de 30 s em um desenho de linha do tempo. Marque a renovação e depois simule falha nessa chamada. Resultado esperado: identifique quando dois workers poderiam trabalhar sobre o mesmo evento e explique como o banco impede aplicar o efeito duas vezes.

O prazo deve equilibrar duração normal e velocidade de recuperação. Use distribuição de duração e margem para exclusão; uma média não representa os trabalhos mais lentos.

Relacionado: 4. Retry, DLQ e Lambda com SQS · Idempotent Operations.

---

Parte de Amazon SQS