Filtragem de mensagens do SQS e integração SNS + SQS

Em uma arquitetura de distribuição sem filtragem, todo assinante do SQS recebe todas as mensagens do SNS. Se o seu tópico publicar eventos de pedidos para 10 categorias diferentes de produtos, mas um assinante processar apenas pedidos de produtos eletrônicos, ele ainda receberá e terá de descartar mensagens de alimentos e roupas. Isso desperdiça recursos computacionais, aumenta os custos e adiciona carga desnecessária aos consumidores. As políticas de filtragem de assinaturas do SNS resolvem esse problema fazendo com que o próprio SNS encaminhe as mensagens apenas aos assinantes apropriados.

Uma política de filtragem é um objeto JSON aplicado a uma assinatura do SQS ou do Lambda. O SNS avalia a política em relação aos atributos da mensagem antes de fazer a entrega. Se os atributos da mensagem corresponderem à política de filtragem, a mensagem será entregue; caso contrário, o SNS ignorará silenciosamente esse assinante. As políticas de filtragem oferecem suporte à correspondência de strings, a intervalos numéricos, à correspondência por prefixo e ao operador exists para verificar a presença ou ausência de um atributo.

Por padrão, as políticas de filtragem fazem a correspondência com base nos atributos da mensagem (metadados). Desde 2023, o SNS também oferece suporte à filtragem baseada na carga útil (corpo), definindo o escopo da política de filtragem como MessageBody. Isso permite filtrar com base em caminhos JSON diretamente no corpo da mensagem, sem exigir que os publicadores adicionem atributos. A filtragem do corpo é mais flexível, mas exige que o corpo da mensagem seja um JSON válido. Confirme sempre qual escopo corresponde ao formato de saída do seu publicador.

As políticas de filtragem oferecem suporte a vários operadores de correspondência além da simples igualdade de strings:

• Numérico: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Prefixo: {"prefix": "order-"} corresponde a qualquer string que comece com esse prefixo
• Qualquer valor, exceto: {"anything-but": ["CANCELLED"]} corresponde a qualquer valor, exceto os listados
• Existência: {"exists": true} corresponde quando o atributo está presente; false quando está ausente

Para que a filtragem funcione, o publicador deve incluir atributos da mensagem ao publicar no SNS. Os atributos são pares de chave e valor com um tipo de dados (String, Number, Binary). O publicador não precisa saber quais assinantes têm quais políticas de filtragem; basta enriquecer a mensagem com atributos que descrevam o evento. O SNS gerencia o roteamento automaticamente. Isso mantém os publicadores totalmente desacoplados da lógica específica dos assinantes.

Uma topologia sofisticada de distribuição pode ter o SNS encaminhando mensagens para filas do SQS em vários níveis de especificidade: uma fila recebe todos os pedidos (sem filtro) para auditoria, outra recebe apenas pedidos HIGH_VALUE (amount >= 1000) para análise de fraude, e uma terceira recebe apenas pedidos ELECTRONICS para o armazém de produtos eletrônicos. Cada fila do SQS tem seu próprio consumidor do Lambda. Esse padrão permite escalar cada camada de processamento de forma independente e adicionar novos consumidores sem alterar os existentes nem o publicador.

O SNS pode entregar mensagens a filas do SQS em uma conta da AWS diferente. A política baseada em recursos da fila do SQS deve permitir que a entidade principal de serviço do SNS chame sqs:SendMessage a partir do ARN do tópico do SNS da conta publicadora. Isso permite a publicação centralizada de eventos (uma conta publica e várias equipes de contas assinam) sem compartilhar credenciais. A distribuição entre contas é um padrão comum em configurações do AWS Organizations com várias contas.

Quando o volume de eventos aumenta repentinamente, as invocações diretas do SNS para o Lambda fazem o Lambda escalar imediatamente, podendo sobrecarregar bancos de dados ou APIs downstream. Adicionar o SQS entre o SNS e o Lambda cria um buffer: o SNS entrega as mensagens ao SQS, e o Lambda consulta o SQS em um tamanho de lote controlado. Isso permite que o Lambda processe as mensagens a uma taxa sustentável enquanto o SQS absorve os picos de tráfego. A profundidade da fila funciona como um mecanismo de contrapressão: você pode monitorá-la e gerar um alerta quando crescer além de um limite que indique atraso do consumidor.

SNS → Lambda (direto): menor latência, sem buffer, o Lambda escala imediatamente. É ideal para alertas em tempo real ou notificações urgentes em que uma latência inferior a um segundo é importante. SNS → SQS → Lambda: adiciona suporte a DLQ, taxa de processamento controlada, novas tentativas com tempo limite de visibilidade e monitoramento da profundidade da fila. É ideal para processamento de transações, atualizações de inventário e qualquer cenário em que seja necessário respeitar os limites dos sistemas downstream. Em questões de exame, escolha o armazenamento intermediário do SQS sempre que forem mencionados durabilidade e controle de taxa.

Use o editor de políticas de filtragem do console do SNS para testar se uma mensagem de exemplo corresponderia à sua política de filtragem antes da implantação. Também é possível usar o ambiente de testes do SNS para simular a entrega de mensagens e verificar o roteamento. No código, valide as políticas de filtragem publicando mensagens de teste com atributos conhecidos e verificando as métricas do CloudWatch para cada assinatura: a métrica NumberOfMessagesFiltered mostra quantas mensagens foram bloqueadas pelo filtro, ajudando a ajustar as políticas sem esperar por eventos de produção.

Uma integração completa entre SNS e SQS funciona assim: (1) a aplicação publica um evento em um tópico Standard do SNS com atributos de mensagem; (2) o SNS avalia a política de filtragem de cada assinatura e entrega apenas as mensagens correspondentes a cada fila do SQS; (3) o Lambda consulta cada fila do SQS em lotes de tamanho configurado e processa as mensagens; (4) as mensagens com falha chegam à DLQ após maxReceiveCount; (5) um alarme do CloudWatch sobre a quantidade de mensagens na DLQ alerta a equipe. Esse padrão totalmente desacoplado e resiliente é um modelo de arquitetura SAA-C03.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: as políticas de filtragem do SNS roteiam mensagens com base nos atributos da mensagem ou no conteúdo do corpo no nível do SNS, eliminando o processamento desnecessário pelos consumidores posteriores; o padrão SNS→SQS→Lambda adiciona armazenamento em buffer durável e controle de taxa entre a transmissão para vários destinos e o processamento; e a entrega do SQS entre contas permite uma publicação/assinatura centralizada em ambientes com várias contas usando políticas de recursos da fila. A seguir, exploraremos as APIs REST, HTTP e WebSocket do Amazon API Gateway.