AWS SAA-C03/07 - Desacoplamento e Integração2 mincheatsheet
Cheatsheet Mensageria
Cheatsheet — Desacoplamento e Integração
Qual serviço por sinal
| Sinal no enunciado | Serviço |
|---|---|
| Fila, worker consome no seu ritmo, absorver pico | SQS |
| Notificar vários destinos ao mesmo tempo (fan-out) | SNS |
| Rotear evento por conteúdo/regra, integrar SaaS | EventBridge |
| Streaming contínuo, replay, múltiplos consumidores lendo o mesmo dado | Kinesis Data Streams |
| Entregar streaming em S3/Redshift sem código | Data Firehose |
| Orquestrar passos com estado, retry, branch | Step Functions |
SQS
| Standard | FIFO | |
|---|---|---|
| Throughput | Ilimitado | 300 msg/s (3.000 com batch de 10) |
| Ordem | Best-effort | Garantida por Message Group ID |
| Entrega | At-least-once (pode duplicar) | Exactly-once |
| Nome da fila | Qualquer | Termina em .fifo |
- Visibility timeout: padrão 30 s, máx 12 h. Curto demais = outro worker pega a mesma mensagem e processa duas vezes.
- Retenção: padrão 4 dias, máx 14 dias.
- Mensagem máx 256 KB — acima disso, Extended Client Library guarda o corpo no S3.
- Long polling (até 20 s) reduz chamadas vazias e custo vs short polling.
- DLQ: após N tentativas, isola a mensagem venenosa pra não travar a fila.
"Desacoplar app de picos de tráfego" → ASG consumindo de SQS, escalando pela métrica ApproximateNumberOfMessagesVisible. Escalar por CPU nesse cenário é a alternativa errada plantada.
SNS
- Pub/sub: um publish → muitos subscribers (SQS, Lambda, HTTP, e-mail, SMS).
- Fan-out SNS → múltiplas SQS é o padrão quando vários sistemas precisam do mesmo evento e cada um processa no próprio ritmo.
- Message filtering entrega só o que casa com o filtro do subscriber.
- SNS FIFO existe, e só entrega para SQS FIFO.
SNS vs SQS vs EventBridge
| SQS | SNS | EventBridge | |
|---|---|---|---|
| Modelo | Pull (fila) | Push (broadcast) | Push (roteamento por regra) |
| Consumidores | 1 por mensagem | N | N, filtrados por padrão de evento |
| Persiste | Até 14 dias | Não (só entrega) | Archive + replay |
| Diferencial | Buffer e retry | Fan-out simples | Filtro rico, schema registry, SaaS, agendamento |
Kinesis
| Data Streams | Data Firehose | |
|---|---|---|
| Gestão | Você gerencia shards | Totalmente serverless |
| Latência | Real time (~200 ms) | Near real time (buffer mín. ~60 s) |
| Retenção / replay | 24 h a 365 dias, com replay | Nenhuma — entrega e descarta |
| Destino | Seu consumidor | S3, Redshift, OpenSearch, Splunk |
Capacidade por shard: 1 MB/s ou 1.000 registros/s de entrada, 2 MB/s de saída.
Sinal: "múltiplas aplicações processando o mesmo stream" ou "reprocessar dados de ontem" → Data Streams. "só jogar no S3 sem manter código" → Firehose.
Idempotência
Como SQS Standard entrega pelo menos uma vez, o consumidor precisa ser idempotente: guarde um ID de deduplicação processado (ex: em DynamoDB) e ignore repetido. A prova cobra isso como "como evitar processamento duplicado sem migrar para FIFO".
Parte de 07 - MOC Desacoplamento e Integração