Messaging: SQS, SNS, EventBridge e Kinesis
- ⬜🎓 SAA-C03: Da Teoria à Arquitetura Real(AWS Solutions Architect Associate)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Desacoplamento é o segredo de sistemas resilientes. Acoplar dois serviços via API síncrona sincroniza falhas — se o downstream cai, o upstream cai junto. AWS oferece 4 primitivos de messaging/streaming: SQS (filas), SNS (pub/sub broadcast), EventBridge (roteamento por regras) e Kinesis (streaming de dados). O SAA cobra quando usar cada um, features específicas (FIFO, DLQ, fanout) e combinações comuns.
Mapa mental: qual serviço para qual problema?
- → enfileira
- → publica
- → emite evento
- → grava no stream
- → fan-out para filas
- → poll
- → após maxReceiveCount
- → regra casou
- → por shard
- → entrega em lote
- Compute
- Integração de apps
- Analytics
- Armazenamento
Quatro perguntas resolvem a escolha: precisa de mais de um consumidor lendo o MESMO dado? (SNS ou Kinesis). Precisa de ordem e replay? (Kinesis). Precisa filtrar por conteúdo? (EventBridge). Só desacoplar e absorver pico? (SQS).
- SQS: uma mensagem, um consumidor. Fila para desacoplar e absorver pico. O consumidor faz poll e apaga a mensagem ao terminar. Se falhar N vezes, vai para a DLQ — sem DLQ, a mensagem circula para sempre e você não descobre. Standard é at-least-once e sem ordem; FIFO garante ordem e exactly-once, com throughput menor.
- SNS: uma mensagem, muitos destinos. Publica no tópico e todos os assinantes recebem, na hora. Sem retenção: quem não estava assinando não recebe depois. É push, não poll.
- O padrão fan-out que o exame adora. SNS na frente, SQS atrás — cada consumidor tem a própria fila, com o próprio ritmo e a própria DLQ. Um consumidor lento não segura os outros, e nada é perdido se um estiver fora. É a resposta canônica de "notificar vários sistemas de forma confiável".
- EventBridge: roteia pelo CONTEÚDO. A diferença sutil em relação ao SNS: aqui a regra inspeciona o corpo do evento e decide o destino. "Pedido acima de R$ 10 mil vai para revisão manual" é regra de EventBridge, não de SNS. Além disso ele recebe evento de serviços AWS e de SaaS de terceiros.
- Kinesis: ordem, replay e vários leitores. Retenção configurável, então você pode reprocessar. Ordem garantida DENTRO do shard — a chave de partição decide o shard, e chave mal escolhida cria hot shard. Quando a questão fala de "ordem", "replay" ou "vários consumidores lendo o mesmo dado", é Kinesis e não SQS.
SQS — filas para desacoplar producer de consumer
| Feature | Standard | FIFO |
|---|---|---|
| Throughput | Ilimitado | 300 msg/s (3.000 com batching, 30.000 com high throughput mode) |
| Ordem | Best-effort | Garantida dentro do MessageGroupId |
| Duplicação | Possível (at-least-once) | Exactly-once via DeduplicationId (5min window) |
| Naming | qualquer | Obrigatório sufixo .fifo |
| Caso | Alta escala, ordem não crítica | Pagamentos, workflows ordenados |
Visibility timeout é pegadinha: se o consumer demora mais que o timeout, a msg reaparece e outro consumer a pega também — dupla execução. Calcule: tempo de processing × 2 + margem. Ou use para estender dinamicamente.
# Criar FIFO com DLQ
aws sqs create-queue --queue-name jobs.fifo \
--attributes FifoQueue=true,ContentBasedDeduplication=true,\
RedrivePolicy='{"deadLetterTargetArn":"arn:aws:sqs:...jobs-dlq.fifo","maxReceiveCount":"5"}'
# Consumir com long polling
aws sqs receive-message --queue-url ... \
--wait-time-seconds 20 --max-number-of-messages 10SNS — pub/sub para fanout
SNS é tópico: publisher publica uma mensagem, N subscribers recebem. Subscribers podem ser SQS, Lambda, HTTP/S, Email, SMS, Mobile Push, Kinesis Firehose.
EventBridge — roteamento de eventos por regras
EventBridge é o evoluído do CloudWatch Events. É event bus: recebe eventos JSON, aplica regras declarativas (pattern matching em JSON) e despacha para até 5 targets por regra. Targets suportados: Lambda, Step Functions, SQS, SNS, Kinesis, ECS task, EC2 start/stop, Batch, API destination (HTTP), e ~20 outros.
{
"source": ["com.ffv.orders"],
"detail-type": ["OrderPlaced"],
"detail": {
"amount": [{ "numeric": [">=", 1000] }],
"region": ["BR", "AR"]
}
}SNS vs EventBridge — a diferença sutil
| Dimensão | SNS | EventBridge |
|---|---|---|
| Conceito | Pub/sub broadcast | Bus de eventos com roteamento inteligente |
| Filtros | Por atributos simples | Pattern matching JSON complexo |
| Throughput | Muito alto (fanout amplo) | Alto mas com overhead de matching |
| Targets | ~6 (SQS, Lambda, HTTP, email, SMS, push) | 20+ nativos AWS |
| Latência | Baixíssima (<100ms) | Baixa (~500ms) |
| Schema discovery | Não | Sim |
| SaaS nativo | Não | Sim (Partner Event Sources) |
| Archive/Replay | Não | Sim |
| Caso ideal | Fanout simples para serviços conhecidos | Arquitetura event-driven complexa com múltiplas fontes |
Três sistemas precisam reagir a "pedido criado": faturamento, estoque e e-mail. O faturamento fica fora do ar por 20 minutos algumas vezes por semana, e nenhum evento pode ser perdido. Qual arquitetura?
Kinesis — streaming de dados
| Variante | Função | Caso de uso |
|---|---|---|
| Kinesis Data Streams | Stream ordenado por shard, retenção 24h–365d | Real-time ingest, múltiplos consumers independentes |
| Kinesis Data Firehose | Delivery managed para S3/Redshift/OpenSearch/Splunk | ETL simples, sem custom processing |
| Kinesis Data Analytics | SQL/Flink sobre streams | Analytics em janela de tempo (tumbling/sliding) |
| Kinesis Video Streams | Ingest de vídeo/áudio | CCTV, ML sobre vídeo, WebRTC |
SQS FIFO vs Kinesis: ambos ordenam, mas: FIFO é fila (1 consumer, remove mensagem após read); Kinesis é stream (N consumers independentes, mensagem persiste por retention). Para analytics com múltiplos pipelines lendo o mesmo dado → Kinesis. Para worker queue → SQS.
Padrões combinados comuns
📋 Evento 'NovoPedido' precisa: enviar email, debitar estoque, registrar em data warehouse
Fanout via SNS garante que cada subscriber receba. SQS dá DLQ e desacoplamento. Se email cair, estoque e warehouse continuam.
Alt: EventBridge → 3 Lambdas — mais moderno; útil se quer filtros por evento.
📋 Ingest de 1 milhão events/s de IoT para análise real-time + armazenar em S3 + alertas
Streams suporta throughput massivo e múltiplos consumers. Firehose entrega batches otimizados para S3. Lambda para regras ad-hoc.
Alt: MSK (Kafka managed) — opção se já usa Kafka ecosystem.
Q&A estilo exame
❓ Consumer SQS está falhando e mensagens ficam voltando. Como evitar infinite loop?
❓ Como garantir que mensagens SQS sejam criptografadas em trânsito e em repouso?
❓ Qual serviço AWS é ideal para reagir a mudanças de estado de recursos (ex: EC2 state change, S3 put)?
❓ SQS FIFO está limitado a 300 msg/s. Como aumentar?
Perguntas frequentes
❓ Fila, tópico, barramento de evento ou fluxo de dados?
❓ Fila padrão ou ordenada?
❓ Para que serve fila de mensagem morta?
Fixando
Um sistema precisa processar eventos na ordem em que ocorreram, permitir que dois serviços diferentes leiam o MESMO evento, e reprocessar as últimas 24 horas se houver bug. Qual serviço?
Qual afirmação distingue corretamente SNS de EventBridge?
Armadilhas: (1) SQS Standard é at-least-once — consumer deve ser idempotente; (2) FIFO ordem só dentro de MessageGroupId; (3) SNS sem SQS na ponta perde mensagens se subscriber cair; (4) Kinesis shards têm limites — planeje partition key; (5) EventBridge regra sem target é no-op silencioso.
Take-aways: SQS = fila 1:1, SNS = pub/sub N:M, EventBridge = roteamento inteligente com filtros e SaaS, Kinesis = stream real-time com retention. Combine: SNS→SQS para fanout durável; EventBridge→SQS/Lambda para event-driven moderno; Kinesis→Firehose→S3 para data lake.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…