SQS, SNS e EventBridge: afinal, quem manda mensagem para quem?

Os três aparecem juntos com tanta frequência em diagrama de arquitetura AWS que é fácil presumir que fazem a mesma coisa com nome diferente. Não fazem. Cada um resolve um formato distinto de comunicação assíncrona, e a confusão some assim que fica claro qual pergunta cada serviço responde.

SQS: uma fila, um consumidor processando por vez

Amazon SQS é uma fila de mensagens ponto a ponto. Um produtor envia mensagem para a fila, e um ou mais consumidores retiram mensagens dali para processar. O ponto central é que cada mensagem é processada uma vez, por um consumidor, mesmo havendo múltiplos consumidores competindo pela mesma fila. Existe um período de visibilidade: enquanto um consumidor está processando uma mensagem, ela fica invisível para os demais, e volta a ficar disponível se aquele processamento não confirmar conclusão a tempo.

SQS resolve bem o cenário de desacoplar produtor e consumidor no tempo, quando existe uma tarefa que precisa ser executada, uma vez, eventualmente, sem que o produtor precise esperar a resposta imediata.

SNS: um aviso, vários interessados ao mesmo tempo

Amazon SNS segue o modelo publish/subscribe. Um produtor publica uma mensagem num tópico, e todo assinante daquele tópico recebe uma cópia, de forma independente dos demais assinantes. Diferente do SQS, a mesma mensagem não é disputada entre consumidores, ela é distribuída para todos que assinaram aquele tópico.

Um padrão comum combina os dois: SNS publica para múltiplas filas SQS assinantes ao mesmo tempo, fan-out, permitindo que sistemas diferentes reajam ao mesmo evento de forma independente, cada um na própria fila, no próprio ritmo de processamento.

EventBridge: roteamento com regra, não só distribuição

EventBridge parte de outro conceito: um barramento de eventos, onde eventos publicados podem ser roteados para múltiplos alvos com base em regras de filtragem sobre o conteúdo e a origem do evento, não apenas sobre a assinatura de um tópico fixo. Isso permite, por exemplo, rotear apenas eventos de um tipo específico, vindos de uma origem específica, para um alvo específico, sem que o produtor precise saber quem vai consumir aquilo.

{
  "source": ["app.pedidos"],
  "detail-type": ["PedidoCancelado"]
}

Uma regra como essa filtra, dentro do barramento, apenas eventos que casam com esse padrão, direcionando para o alvo configurado, seja uma fila SQS, uma função Lambda ou outro serviço integrado.

Então qual usar, afinal?

A pergunta certa não é qual dos três é melhor, é qual formato de comunicação a situação exige. Fila (SQS) quando existe uma tarefa que precisa ser processada uma vez, de forma confiável, por algum consumidor disponível. Tópico (SNS) quando o mesmo evento precisa chegar a múltiplos interessados, cada um agindo de forma independente. Barramento de eventos (EventBridge) quando o roteamento depende do conteúdo do evento, com regras de filtragem, e não apenas de quem assinou o quê.

Também não são mutuamente exclusivos dentro da mesma arquitetura. É comum ver EventBridge roteando para filas SQS, ou SNS alimentando múltiplas filas em fan-out, cada peça cobrindo a parte do problema para a qual foi desenhada.

O nome confunde mais do que o conceito

Boa parte da confusão entre os três não vem da complexidade real do problema, vem do fato de os nomes não deixarem óbvio, à primeira vista, qual é ponto a ponto, qual é distribuição e qual é roteamento por regra. Uma vez que essa distinção fica clara, escolher entre eles deixa de ser adivinhação e vira uma questão de mapear o formato da comunicação necessária para o serviço desenhado exatamente para aquele formato.