AWS SAA-C03/07 - Desacoplamento e Integração2 min
SQS
Responda com suas palavras antes de ler o resto da nota.
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off (custo, latência, operação)?
- Que sinal no enunciado aponta pra isso?
- Com o que isso é confundido na prova?
Conceito
Fila gerenciada que desacopla produtor e consumidor. O produtor escreve e segue a vida; o consumidor lê no ritmo dele. É o amortecedor de pico mais cobrado da prova.
| 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 | Qualquer | Termina em .fifo |
Parâmetros que caem em prova
| Parâmetro | Padrão | Máximo |
|---|---|---|
| Visibility timeout | 30 s | 12 h |
| Message retention | 4 dias | 14 dias |
| Tamanho da mensagem | — | 256 KB |
Long polling (WaitTimeSeconds) |
0 | 20 s |
| Delay queue | 0 | 15 min |
- Visibility timeout curto demais = outro worker pega a mesma mensagem e processa duas vezes. Se o processamento é longo, aumente ou chame
ChangeMessageVisibility. - Mensagem maior que 256 KB → SQS Extended Client Library, que guarda o corpo no S3 e passa só a referência.
- Long polling reduz chamadas vazias e custo — sempre preferível ao short polling.
- DLQ (Dead-Letter Queue): depois de N tentativas (
maxReceiveCount), a mensagem venenosa é isolada pra não travar a fila.
O padrão que a prova ama
produtor → SQS → Auto Scaling Group de workers
escalando por ApproximateNumberOfMessagesVisible
Escalar por CPU nesse cenário é a alternativa errada plantada: o worker pode estar ocioso em CPU e com backlog enorme.
Trade-offs
Standard entrega throughput ilimitado e pode duplicar — o consumidor precisa ser idempotente. FIFO garante ordem e unicidade e limita o throughput; se o enunciado não pedir ordem explicitamente, Standard é a resposta.
Fila desacopla e adiciona latência: a resposta deixa de ser síncrona. Quando o cliente precisa de resposta imediata, fila não serve — ou serve com um mecanismo de polling/notificação por cima.
Sinais de prova
- "Absorver pico de tráfego sem perder requisição" → SQS
- "Ordem de processamento importa" → FIFO
- "Evitar processamento duplicado sem migrar pra FIFO" → idempotência no consumidor
- "Mensagem de 1 MB" → Extended Client + S3
- "Mensagem falha e trava a fila" → DLQ
- "Reduzir custo de chamadas vazias" → long polling
- "Worker demora 20 min e a mensagem reaparece" → aumentar visibility timeout
- "Escalar workers conforme a demanda" → ASG na métrica da fila, não CPU
Relacionado
Parte de 07 - MOC Desacoplamento e Integração · Documentação AWS