Arquitetura Orientada a Eventos na AWS: SQS, SNS e EventBridge

A maior parte dos incidentes de indisponibilidade em sistemas distribuídos não vem de um serviço individual falhando — vem de um serviço que falhou e derrubou junto todos os que dependiam dele de forma síncrona. Uma arquitetura orientada a eventos existe justamente para quebrar essa cadeia: em vez de um serviço chamar o outro diretamente e esperar resposta, ele publica um evento e segue em frente, deixando que quem precisa reagir a esse evento o faça no seu próprio ritmo. Na AWS, essa comunicação assíncrona tem três pilares com propósitos bem diferentes — Amazon SQS, Amazon SNS e Amazon EventBridge — e a maior parte dos problemas de arquitetura de eventos que aparecem em produção vem de usar o serviço errado para o padrão de comunicação errado. Este guia explica o que cada um resolve, quando combiná-los, e os padrões de resiliência que separam uma arquitetura de eventos madura de uma coleção de filas acopladas por acidente.

O Que É Arquitetura Orientada a Eventos e Por Que Ela Importa

Arquitetura orientada a eventos é um estilo de desenho de sistemas em que componentes se comunicam emitindo e reagindo a eventos, em vez de fazerem chamadas diretas e síncronas uns aos outros. Um evento é simplesmente o registro de algo que aconteceu — "pedido criado", "pagamento aprovado", "arquivo enviado" — publicado por quem produziu a mudança de estado, sem que o produtor precise saber quem (ou quantos) vão consumir esse evento.

O ganho central é o desacoplamento temporal e estrutural. Temporal porque o produtor não fica bloqueado esperando o consumidor processar — ele publica e segue. Estrutural porque o produtor não precisa conhecer a lista de consumidores: adicionar um novo serviço que reage ao mesmo evento não exige alterar o código de quem publica. Isso tem um preço: depurar um fluxo que atravessa cinco serviços assíncronos é mais difícil do que seguir uma pilha de chamadas síncronas, e a ordem de processamento deixa de ser garantida por padrão. A arquitetura orientada a eventos troca previsibilidade de fluxo por resiliência e capacidade de escalar cada parte do sistema de forma independente — troca que faz sentido para a maioria dos sistemas distribuídos modernos, mas que precisa ser uma escolha consciente, não um acidente de arquitetura.

Na AWS, esse desacoplamento é implementado por três serviços gerenciados com modelos de entrega diferentes: filas (Amazon SQS), publicação/assinatura simples (Amazon SNS) e um barramento de eventos com roteamento por regras (Amazon EventBridge). Entender a diferença entre eles é o primeiro filtro de decisão de qualquer arquitetura de eventos na nuvem.

Amazon SQS: Filas Para Desacoplar Produtor e Consumidor

O Amazon SQS é um serviço de filas gerenciado: um produtor envia mensagens para uma fila, e um ou mais consumidores as retiram para processar. A mensagem permanece armazenada de forma redundante até ser processada e explicitamente removida — o que dá ao SQS uma característica que SNS e EventBridge não têm por padrão: se não houver consumidor disponível no momento, a mensagem simplesmente espera na fila em vez de se perder.

Standard vs. FIFO: a decisão que define o resto

O SQS oferece dois tipos de fila, e a escolha entre eles é a primeira decisão técnica de qualquer implementação:

Filas standard oferecem throughput praticamente ilimitado e entrega at-least-once — uma mensagem pode, em situações raras, ser entregue mais de uma vez, e a ordem de entrega não é garantida. Para a maioria dos casos de uso (notificações, eventos de log, processamento paralelo massivo) isso é aceitável e até desejável, porque o sistema escala sem limites artificiais de ordenação.

Filas FIFO garantem ordem estrita de processamento dentro do mesmo message group e entrega exatamente uma vez (exactly-once processing), usando um MessageGroupId para definir o particionamento da ordem e um MessageDeduplicationId (ou hash automático do corpo) para descartar duplicatas dentro de uma janela de deduplicação de 5 minutos. O custo é throughput mais limitado: sem agrupamento em lote, uma fila FIFO padrão processa até 300 mensagens por segundo; com batching, até 3.000 mensagens por segundo. O modo de alto throughput (high throughput mode) eleva esse teto para até 4.000 mensagens por segundo sem lote e 40.000 com lote, distribuindo a carga entre partições internas — mas exige desenhar os MessageGroupId pensando em paralelismo, não só em ordem.

A regra prática: use FIFO quando a ordem ou a ausência de duplicatas é um requisito de negócio real — processamento de pagamentos, aplicação sequencial de eventos de um mesmo pedido, workflows com dependência estrita entre etapas. Use standard para tudo que tolera reprocessamento e não depende de ordem, que é a maioria dos casos — e que se beneficia de throughput sem teto artificial.

Visibility timeout e o ciclo de vida da mensagem

Quando um consumidor recebe uma mensagem, ela não é removida da fila imediatamente — ela fica invisível para outros consumidores durante o visibility timeout, e só é apagada de fato quando o consumidor confirma o processamento (DeleteMessage). Se o consumidor falhar ou travar antes de confirmar, a mensagem volta a ficar visível quando o timeout expira, e é entregue novamente. Esse mecanismo é o que torna o SQS resiliente a falha de consumidor — e também o motivo pelo qual todo consumidor de SQS precisa ser projetado para tolerar reprocessamento (mais sobre isso na seção de idempotência).

Amazon SNS: Publicação/Assinatura e o Padrão Fan-Out

O Amazon SNS resolve um problema diferente do SQS: em vez de um único consumidor retirando mensagens de uma fila, o SNS distribui a mesma mensagem, publicada uma única vez em um tópico, para múltiplos assinantes simultaneamente — o padrão conhecido como fan-out. Um tópico SNS pode ter como assinante uma fila SQS, uma função Lambda, um endpoint HTTP(S), um e-mail, uma mensagem SMS, ou um serviço terceiro (Datadog, MongoDB, Splunk, entre outros).

O caso canônico de fan-out: um evento de "pedido criado" é publicado uma vez no tópico SNS, e três sistemas completamente independentes reagem em paralelo — uma fila SQS que alimenta o processo de fulfillment, outra fila que alimenta o data warehouse para análise, e uma função Lambda que dispara o e-mail de confirmação para o cliente. Nenhum desses três consumidores sabe da existência dos outros dois, e adicionar um quarto consumidor no futuro não exige tocar no código de quem publica o evento.

Uma prática recomendada quase universal é combinar SNS com SQS mesmo quando o objetivo final é notificar um único sistema: publicar em SNS e assinar via uma fila SQS, em vez de assinar diretamente com Lambda ou HTTP, dá ao consumidor a resiliência de fila (mensagem não se perde se o consumidor estiver fora do ar) que o SNS sozinho não oferece — SNS tenta entregar e descarta segundo sua própria política de retry, sem persistência indefinida como o SQS.

Amazon EventBridge: o Barramento de Eventos com Roteamento Inteligente

O Amazon EventBridge vai além do fan-out simples do SNS: em vez de um tópico com assinantes fixos, o EventBridge organiza eventos em um event bus — um roteador que recebe eventos de múltiplas fontes e os entrega a zero ou mais destinos, com base em regras de correspondência de conteúdo, não apenas em uma lista estática de assinantes.

Regras, filtragem por conteúdo e integração com SaaS

Uma rule no EventBridge define um padrão de correspondência (event pattern) que examina os campos do evento — tipo, origem, atributos do payload — e decide para quais alvos ele deve ser roteado. Isso permite que múltiplas equipes consumam subconjuntos diferentes do mesmo fluxo de eventos sem que o produtor precise saber quem está interessado em quê, e sem exigir um tópico dedicado para cada combinação de interesse. É a diferença estrutural mais relevante frente ao SNS: SNS distribui para quem está inscrito no tópico; EventBridge roteia com base no conteúdo do evento.

O EventBridge também integra nativamente com dezenas de aplicações SaaS de terceiros como fontes de eventos — parceiros que publicam eventos diretamente em um partner event bus na conta AWS do cliente, sem exigir polling ou webhooks customizados —, além de receber eventos nativos de praticamente todos os serviços da AWS (mudança de estado no S3, no EC2, no DynamoDB Streams) e eventos customizados publicados pela própria aplicação.

Schema Registry: contrato de dados para os eventos

O Schema Registry do EventBridge coleta e organiza os esquemas dos eventos que trafegam pelo barramento — incluindo descoberta automática de esquema a partir dos eventos reais que passam pelo bus (schema discovery) — e permite gerar código de binding para o formato desses eventos em linguagens como Java, Python e TypeScript. Isso resolve um problema real de arquiteturas de eventos maduras: sem um contrato explícito, cada equipe consumidora precisa inferir o formato do evento lendo exemplos, e mudanças silenciosas de schema quebram consumidores sem aviso.

EventBridge Pipes: integração ponto a ponto com enriquecimento

Para o caso mais específico de conectar uma única origem a um único destino — por exemplo, um DynamoDB Stream alimentando um event bus — o EventBridge Pipes oferece transformação e enriquecimento do evento antes da entrega, sem exigir uma função Lambda intermediária só para reformatar o payload. Pipes e event bus costumam ser usados em conjunto: o pipe recebe de uma fonte única, processa, e entrega ao bus, que então roteia para múltiplos alvos segundo as regras configuradas.

SQS vs. SNS vs. EventBridge: Como Escolher (ou Combinar os Três)

Não existe "o melhor dos três" de forma absoluta — cada um resolve um problema estrutural diferente, e a maioria das arquiteturas de eventos maduras usa mais de um ao mesmo tempo (SNS publicando para filas SQS é o exemplo mais comum). A tabela abaixo resume o critério de escolha:

Um padrão comum em arquiteturas reais: EventBridge recebe e roteia os eventos de negócio de mais alto nível (o "o que aconteceu" da aplicação), SNS cuida do fan-out quando um mesmo evento precisa notificar vários sistemas ao mesmo tempo, e SQS aparece como a camada final de buffer antes de cada consumidor processar — absorvendo picos de carga e dando tempo para o consumidor se recuperar de uma indisponibilidade momentânea sem perder mensagem.

Padrões de Resiliência: Dead-Letter Queue, Idempotência e Retry

Um sistema orientado a eventos que não trata falha como parte normal do fluxo não é resiliente — só está adiando o problema para o dia em que a falha realmente acontecer em produção.

Dead-letter queue (DLQ) e redrive policy

Uma dead-letter queue é uma fila secundária para onde mensagens que falharam repetidamente são desviadas, em vez de ficarem sendo tentadas indefinidamente ou se perdendo silenciosamente. A redrive policy define o maxReceiveCount — quantas vezes uma mensagem pode ser recebida sem ser deletada antes de ser movida para a DLQ. Um maxReceiveCount baixo demais move mensagens para a DLQ por falhas transitórias que se resolveriam numa nova tentativa; um valor alto demais mantém uma mensagem realmente inválida circulando por tempo excessivo, consumindo capacidade de processamento. Boa prática: configurar retenção da DLQ mais longa que a da fila de origem, já que o relógio de expiração da mensagem não reinicia ao ser movida (em filas standard) — e configurar um alarme no CloudWatch para qualquer mensagem que chegue à DLQ, porque cada uma representa um caso que exige investigação manual.

Idempotência: o requisito não negociável

Tanto SQS quanto SNS e EventBridge operam, por padrão, sob entrega at-least-once — a mesma mensagem pode, em cenários de falha de rede ou timeout, ser entregue mais de uma vez. Isso não é uma falha do serviço, é uma característica inerente de sistemas distribuídos que priorizam disponibilidade. A consequência prática é que todo consumidor de eventos precisa ser idempotente: processar a mesma mensagem duas vezes deve produzir o mesmo resultado que processá-la uma única vez, tipicamente guardando um identificador de operação já processada (o próprio MessageDeduplicationId, um ID de negócio, ou um hash do payload) e verificando esse identificador antes de aplicar o efeito colateral novamente.

Retry com backoff exponencial

Quando um consumidor falha ao processar um evento, tentar novamente imediatamente e sem controle tende a agravar o problema — especialmente se a falha foi causada por sobrecarga do próprio sistema de destino. O padrão recomendado é retry com backoff exponencial e jitter: o intervalo entre tentativas cresce a cada falha (com uma variação aleatória para evitar que múltiplos clientes retentem no mesmo instante exato), dando tempo para o sistema de destino se recuperar antes da próxima tentativa. O visibility timeout do SQS já implementa parte desse comportamento nativamente; para lógica de retry mais sofisticada dentro do próprio consumidor, vale considerar um orquestrador como o AWS Step Functions, coberto no guia de <a href="https://dominit.com.br/arquitetura-serverless-aws-lambda-step-functions/">arquitetura serverless na AWS</a>.

Integração com Lambda e Microsserviços

Na prática, a maior parte das arquiteturas de eventos na AWS termina em uma função Lambda como consumidor — seja lendo de uma fila SQS, de um tópico SNS, ou reagindo a uma regra do EventBridge, como já detalhado no guia de <a href="https://dominit.com.br/arquitetura-serverless-aws-lambda-step-functions/">Lambda, Step Functions e API Gateway</a>.

Quando o Lambda consome uma fila SQS, ele usa um event source mapping: o serviço faz o polling da fila internamente e invoca a função de forma síncrona, entregando um lote de mensagens por invocação (até 10 por padrão). Um detalhe que costuma pegar equipes desavisadas: se a função falhar ao processar o lote inteiro, por padrão todas as mensagens do lote voltam a ficar visíveis na fila — inclusive as que já tinham sido processadas com sucesso antes da falha —, a menos que a função implemente partial batch response informando explicitamente quais mensagens do lote falharam. Sem esse tratamento, uma falha isolada em uma única mensagem de um lote de dez pode gerar reprocessamento de nove mensagens que já tinham sido concluídas corretamente — outro motivo pelo qual idempotência não é opcional.

Para cargas com exigência real de baixa latência e alto volume, o Lambda também oferece provisioned mode para event source mappings de SQS, com pollers dedicados que escalam de forma mais previsível do que o modo sob demanda padrão — relevante para cenários como processamento de feeds financeiros ou personalização em tempo real, onde a variação de latência do polling padrão é inaceitável.

É exatamente esse desacoplamento via eventos — em vez de chamadas HTTP síncronas entre serviços — que permite que uma arquitetura de microsserviços escale cada componente de forma independente: um serviço de pedidos publica um evento de "pedido criado" sem precisar saber (nem esperar resposta) do serviço de estoque, do serviço de faturamento ou do serviço de notificação que reagem a esse mesmo evento, cada um no seu próprio ritmo e com sua própria capacidade de processamento.

Custos e Métricas Para Acompanhar

Os três serviços seguem modelo de cobrança por uso, sem custo fixo de infraestrutura — o que os torna atrativos tanto para cargas pequenas quanto para picos imprevisíveis, já que não há capacidade provisionada ociosa sendo paga. O SQS oferece uma camada gratuita mensal (1 milhão de requisições, válida em todas as regiões da conta) e cobra por requisição de API a partir daí, com payloads acima de 64 KB contando como requisições adicionais proporcionais ao tamanho. SNS cobra por mensagem publicada e por notificação entregue, com preço variando por tipo de endpoint (entrega para SQS ou Lambda tem custo diferente de SMS, por exemplo). EventBridge cobra por evento publicado no barramento personalizado, com eventos nativos de serviços AWS tratados de forma diferenciada dos eventos customizados.

Do ponto de vista de métricas operacionais, vale acompanhar de perto: ApproximateNumberOfMessagesVisible (fila crescendo indica consumidor mais lento que produtor), ApproximateAgeOfOldestMessage (mensagens envelhecendo na fila é sinal de atraso real, não só de volume), taxa de mensagens na DLQ, e taxa de correspondência de regras no EventBridge (uma regra que nunca casa pode indicar um bug silencioso no padrão de filtro). Esse tipo de observabilidade se conecta diretamente com o que já foi coberto no guia de <a href="https://dominit.com.br/observabilidade-aws-cloudwatch-xray-guia-avancado/">observabilidade na AWS com CloudWatch e X-Ray</a> — sistemas assíncronos exigem ainda mais disciplina de monitoramento do que sistemas síncronos, justamente porque uma falha não aparece como erro imediato na tela do usuário.

Casos de Uso Por Porte de Empresa

Para empresas menores, com poucos sistemas e equipe enxuta, o ponto de entrada mais simples costuma ser uma fila SQS standard entre dois ou três serviços — um buffer que absorve picos de carga (por exemplo, entre um formulário de cadastro e o processamento de boas-vindas) sem exigir desenho de barramento de eventos completo. É pouco código, pouca configuração, e resolve o problema real da maioria das aplicações nesse estágio.

Empresas de médio porte com múltiplos times e serviços já se beneficiam de introduzir SNS para os eventos que precisam alcançar mais de um consumidor — o momento em que "esse evento também precisa disparar uma notificação por e-mail" deixa de ser exceção e vira padrão recorrente.

Empresas maiores, com dezenas de serviços e múltiplas equipes publicando e consumindo eventos de origens heterogêneas — incluindo integrações com sistemas SaaS de terceiros —, tendem a justificar o investimento em um event bus do EventBridge com Schema Registry, onde o contrato explícito de dados e o roteamento por regra deixam de ser luxo e passam a ser a única forma prática de manter dezenas de times trabalhando sobre o mesmo fluxo de eventos sem quebrar uns aos outros. É também o estágio em que vale revisitar a arquitetura completa contra as boas práticas descritas no <a href="https://dominit.com.br/aws-well-architected-framework-guia-avancado/">AWS Well-Architected Framework</a>, especialmente os pilares de confiabilidade e excelência operacional.

Perguntas Frequentes sobre Arquitetura Orientada a Eventos na AWS

Qual a diferença prática entre Amazon SQS e Amazon SNS?

SQS é uma fila: mensagens ficam armazenadas até um consumidor processá-las e removê-las, normalmente com um único grupo de consumidores por fila. SNS é publicação/assinatura: uma mensagem publicada em um tópico é replicada para todos os assinantes simultaneamente (fan-out), sem persistência própria além da tentativa de entrega — por isso é comum assinar um tópico SNS com uma fila SQS para ganhar a resiliência de armazenamento que o SNS sozinho não oferece.

Quando vale a pena usar EventBridge em vez de SNS?

Quando o roteamento precisa ser decidido pelo conteúdo do evento (não apenas por uma lista fixa de assinantes de um tópico), quando há necessidade de integrar eventos de aplicações SaaS de terceiros, ou quando o número de tipos de evento e consumidores cresce a ponto de um contrato de dados explícito (Schema Registry) se tornar necessário para manter times diferentes sincronizados.

Fila SQS FIFO é sempre a escolha mais segura?

Não. FIFO garante ordem e evita duplicatas, mas com throughput mais limitado que filas standard (até 4.000 mensagens por segundo sem lote, mesmo no modo de alto throughput, contra throughput praticamente ilimitado em standard). Usar FIFO por padrão em cenários que não exigem ordem estrita é pagar um custo de capacidade sem necessidade real.

O que acontece se uma mensagem falhar repetidamente no processamento?

Se a fila tiver uma dead-letter queue configurada com uma redrive policy, a mensagem é movida para lá depois de exceder o maxReceiveCount definido, isolando-a para investigação em vez de deixá-la sendo tentada indefinidamente ou se perdendo. Sem DLQ configurada, o comportamento padrão é a mensagem continuar sendo reentregue até expirar pelo período de retenção da fila.

Um consumidor de eventos precisa mesmo ser idempotente?

Sim, na prática é obrigatório. Os três serviços operam por padrão sob garantia de entrega at-least-once (exceto filas e tópicos FIFO, que garantem exactly-once dentro das suas condições específicas), o que significa que a mesma mensagem pode chegar mais de uma vez ao consumidor em cenários de falha ou timeout. Um consumidor que não trata isso corretamente pode duplicar efeitos colaterais — cobrar duas vezes, enviar dois e-mails, duplicar um registro.

Dá para combinar SQS, SNS e EventBridge no mesmo sistema?

Sim, e é o padrão mais comum em arquiteturas maduras: EventBridge roteando eventos de negócio de alto nível, SNS fazendo fan-out quando um evento precisa alcançar múltiplos sistemas, e SQS como camada de buffer final antes de cada consumidor processar — cada serviço resolvendo a parte do problema para a qual foi desenhado, em vez de forçar um único serviço a cobrir os três papéis.

Como a comunicação por eventos se relaciona com uma arquitetura de microsserviços?

É a forma mais comum de manter microsserviços desacoplados de verdade: em vez de um serviço chamar o outro via API síncrona e ficar bloqueado esperando resposta, ele publica um evento e cada serviço interessado reage de forma independente, no seu próprio ritmo e com sua própria capacidade de escalar — evitando que uma falha ou lentidão em um serviço se propague em cascata para todos os que dependem dele.

Arquitetura de Eventos Como Base Para Sistemas Resilientes, Não Como Modismo

Adotar SQS, SNS e EventBridge não é sobre seguir uma tendência de arquitetura — é sobre reconhecer que sistemas fortemente acoplados por chamadas síncronas têm um teto de resiliência e escalabilidade que comunicação assíncrona ajuda a remover. A parte que mais separa uma arquitetura de eventos madura de uma coleção de filas acopladas por acidente não é a escolha entre SQS, SNS ou EventBridge isoladamente, mas a disciplina em torno delas: idempotência tratada como requisito, não como detalhe; dead-letter queues monitoradas, não esquecidas; e o serviço certo escolhido para o padrão de comunicação real do sistema, não para o que é mais familiar para quem está desenhando.

Empresas que tratam esses três serviços como peças complementares — cada uma resolvendo o problema estrutural para o qual foi desenhada — constroem sistemas que absorvem picos de carga, falhas parciais e crescimento de complexidade sem reescrever a arquitetura a cada novo serviço adicionado.

Artigos Relacionados

Para aprofundar em temas conectados à arquitetura orientada a eventos:

• Arquitetura Serverless na AWS: Lambda, Step Functions e API Gateway — como Lambda consome eventos de filas, tópicos e regras, e quando usar Step Functions para orquestrar fluxos com múltiplas etapas.
• Observabilidade na AWS: CloudWatch, X-Ray e o Guia Avançado de Monitoramento Distribuído — a disciplina de monitoramento que sistemas assíncronos exigem para não esconder falhas atrás de filas crescendo silenciosamente.
• AWS Well-Architected Framework: o Guia Avançado — os pilares de confiabilidade e excelência operacional que ajudam a validar se uma arquitetura de eventos está realmente pronta para produção.
• FinOps AWS: o Guia Completo para Reduzir Custos na Nuvem — como o modelo de cobrança por uso do SQS, SNS e EventBridge se encaixa em uma estratégia de otimização de custo mais ampla.