Messaging: SQS, SNS, EventBridge e Kinesis
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?
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 |
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 —
📋 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) —
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?
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.
Discussão
Carregando…