APRENDER. PRATICAR. EVOLUIR.Desenhar entrega e efeito separadamente
Num batch fictício de fundos, publicar o evento, recebê-lo e aplicar o resultado são três observações diferentes. SQS Standard admite duplicados; usa identidade estável da operação e proteção dos efeitos. Não apagues uma mensagem antes de confirmar o resultado necessário. Em chamadas batch SQS, HTTP 200 pode acompanhar entradas Successful e Failed. Reconcilia os IDs e trata apenas as entradas falhadas segundo o erro, sem repetir os efeitos já confirmados. Um novo ReceiveMessage fornece outro receipt handle: usa o mais recente para DeleteMessage. O sucesso de um pedido com handle antigo pode não significar eliminação. No handover, mostra qual identificador acompanha cada fase e como se investiga uma confirmação perdida.
Separar os relógios da fila
Delay adia a primeira disponibilidade; visibility timeout protege temporariamente trabalho já recebido. Um processamento de noventa segundos com visibilidade de trinta pode voltar a ser entregue: dimensiona ou prolonga o prazo, mantendo idempotência. Heartbeats não renovam indefinidamente a janela máxima de doze horas desde o pedido ReceiveMessage; divide trabalho longo ou avalia outra orquestração. Timers individuais de mensagens não são suportados em FIFO, embora exista delay ao nível da fila. Para long polling, o timeout HTTP do cliente deve exceder WaitTimeSeconds. No exercício, assinala envio, receção, prorrogação, conclusão e eliminação numa linha temporal; identifica exatamente qual relógio explica cada sintoma antes de aumentar todos os valores.
Observar capacidade e trabalho por resolver
Uma resposta de polling sem mensagens não prova ausência de backlog. Ao atingir o limite de mensagens in flight, long polling pode deixar de devolver novas mensagens sem erro OverLimit. Revê trabalho recebido mas não eliminado, duração, falhas e confirmações. Uma DLQ isola mensagens persistentemente falhadas segundo a política; continuam a representar trabalho por resolver. Antes de redrive, corrige a causa e verifica efeitos anteriores. Para dimensionar workers, quarenta segundos de espera tolerada divididos por dois segundos por mensagem dão um alvo inicial de vinte mensagens por worker no modelo sequencial. Valida variação e limites do destino antes de aumentar concorrência. O relatório deve separar velocidade de escoamento, idade da fila e resultados de negócio.
Validar fanout e configuração de publicação
Quando auditoria e reconciliação precisam de cada evento, SNS com uma fila SQS por consumidor permite processamento independente. Dois consumidores da mesma fila repartem trabalho e não garantem essa cópia por equipa. Confirma também o formato contratado: numa subscrição SQS com raw delivery, mais de dez atributos pode impedir entrega; desativar raw muda o envelope e exige adaptar o consumidor. Alterações de filtros SNS podem demorar até quinze minutos a propagar, pelo que uma observação imediata não encerra a validação. Em EventBridge, inspeciona resultados por entrada de PutEvents. Publicar para um bus inexistente pode devolver 200 sem contabilizar falha; inclui existência do destino, regras e observação do consumidor na aceitação.
Preservar ordem útil e evitar realimentação
Notificações S3 podem chegar fora de ordem. Para eventos PUT ou DELETE da mesma chave, compara sequencer como valor hexadecimal, normalizando comprimentos; não o uses como ordem global entre chaves diferentes. No modelo local, 10 hexadecimal é posterior a f, apesar de uma comparação textual ingénua sugerir o contrário. Se uma função lê ficheiros de entrada e escreve resultados no mesmo bucket, uma notificação demasiado ampla pode voltar a invocá-la. Separa buckets ou restringe o trigger ao prefixo de entrada e mantém resultados fora dele. Uma tarefa curta e independente pode adequar-se a Lambda; valida duração, dependências, acesso e custo. O diagrama deve incluir todas as escritas da função, não apenas o evento que inicia a primeira execução.
Entregar um plano de falhas por integração
Lambda com um event source mapping SQS faz polling e invoca a função de forma síncrona. Falhas persistentes precisam da política de redrive na fila de origem; uma DLQ configurada apenas para invocação assíncrona da função não substitui esse mecanismo. Já um Invoke com InvocationType=Event e resposta 202 confirma aceitação para processamento assíncrono, não a conclusão do efeito de negócio. Reserva vinte minutos para interpretar as respostas sintéticas abaixo e entregar uma matriz com integração, condição de sucesso, retry, isolamento, responsável e recuperação. Inclui uma amostra rejeitada, uma repetida e uma confirmação perdida. Os exemplos e resultados locais são fictícios, sem chamadas AWS nem práticas internas BNP Paribas. O RUN deve receber limites claros sobre aquilo que ainda precisa de ensaio autorizado.
// Synthetic response interpretation only; no queue, SDK, or network calls.
const batch = {Successful: [{Id: 'a'}, {Id: 'c'}], Failed: [{Id: 'b', Code: 'InternalError', SenderFault: false}]};
const retryIds = batch.Failed.filter(x => !x.SenderFault).map(x => x.Id);
const laterOnSameKey = (next, previous) => {
const width = Math.max(next.length, previous.length);
return next.toLowerCase().padStart(width, '0') > previous.toLowerCase().padStart(width, '0');
};
const remainingVisibilitySeconds = 12 * 3600 - 11 * 3600;
console.log(JSON.stringify({retryIds, tenAfterF: laterOnSameKey('10', 'f'), fAfterTen: laterOnSameKey('f', '10'), remainingVisibilitySeconds}));
Um batch responde 200, mas b está em Failed. Regista a falha individual e prepara recuperação de b, preservando os resultados já confirmados.
Armadilhas comuns
Confundir 200 ou 202 com conclusão; usar handle antigo; renovar visibilidade sem limite; aplicar configuração assíncrona ao polling SQS.
Tópicos relacionados: Filas, ordenação e falhas parciais · Eventos: permissões, capacidade e custos · Bases de dados, réplicas e cache
Uma integração resiliente observa cada fronteira e recupera trabalho sem assumir que a aceitação confirmou o efeito.
Referência: SQS standard queues · SAA-C03