Arquiteturas resilientes · tema 12 de 18
Desacoplamento: SQS, SNS e EventBridge
40 min · 2 vídeos · 13 cards · 1 drill
Por que cai
Desacoplar é a resposta estrutural do Domínio 2: componentes que falham juntos viram componentes que falham sozinhos. A prova testa a escolha entre os três serviços com pistas precisas — 'processar depois' é fila, 'avisar vários' é tópico, 'rotear por conteúdo do evento' é EventBridge — e cobra o que acontece com a mensagem quando o consumidor falha.
Pré-teste · 1 de 2
responda antes de verUm serviço web recebe picos de pedidos que derrubam o processamento, e pedidos são perdidos. A empresa quer garantir que nenhum pedido se perca e que o processamento aconteça no ritmo possível. Qual solução atende?
Vídeo · português · 24 min
Em uma frase
Desacoplar é pôr algo entre dois componentes para que a falha ou a lentidão de um não derrube o outro: fila quando é preciso reter e processar depois, tópico quando é preciso avisar vários, barramento quando a decisão depende do conteúdo do evento.
Os três, e a pista de cada um
| SQS | SNS | EventBridge | |
|---|---|---|---|
| Modelo | Fila: um consumidor por mensagem | Tópico: todos os assinantes recebem | Barramento: regras roteiam por conteúdo |
| Retenção | Até 14 dias | Nenhuma: entrega e esquece | Nenhuma (arquivamento é opcional e à parte) |
| Se o destino está fora | A mensagem espera na fila | A entrega falha ou tenta de novo conforme a política | A regra tenta de novo e pode ir para DLQ |
| Pista no enunciado | 'Absorver pico', 'processar depois', 'não perder' | 'Avisar vários sistemas', 'notificar por e-mail e SMS' | 'Conforme o tipo do evento', 'reagir a um serviço da AWS', 'agendar' |
O mecanismo da fila que vira questão
Ler uma mensagem não a remove. O que acontece é:
- 1O consumidor lê a mensagem, que fica invisível para os outros durante o tempo de visibilidade.
- 2Se o processamento termina, o consumidor APAGA a mensagem. Só aí ela deixa a fila.
- 3Se o consumidor falha ou morre antes de apagar, o tempo expira e a mensagem volta a ficar visível, para outro consumidor tentar.
- 4Se ela falhar N vezes, a fila de mensagens mortas a recebe, tirando-a do ciclo.
Esse desenho é o que dá tolerância a falha do consumidor — e é também a origem do sintoma mais cobrado: "a mesma mensagem é processada repetidas vezes e nunca sai". As duas causas são não apagar a mensagem e não ter DLQ configurada.
Leque: tópico com filas
Quando o mesmo evento precisa alimentar vários sistemas, e cada um tem ritmo e tolerância a falha diferentes, nem fila nem tópico sozinhos bastam:
- Fila sozinha entrega a um consumidor: os outros não veem.
- Tópico sozinho entrega e esquece: o sistema que estava fora perde.
O desenho que a prova espera é o leque: um tópico SNS com uma fila SQS assinando para cada destino. O tópico multiplica; cada fila retém e isola. Se o faturamento cair, a fila dele acumula e os outros dois seguem.
Escalar pela fila, não pela CPU
Um grupo de Auto Scaling que consome fila deve escalar pela profundidade da
fila — ApproximateNumberOfMessagesVisible, ou a razão de mensagens por
instância. A CPU do consumidor não representa o trabalho pendente: uma fila com
dez mil mensagens e um consumidor ocioso aguardando entrada de rede tem CPU
baixa. Nas questões, CPU é o distrator e profundidade da fila é a resposta.
Como responder o cenário
Pergunte primeiro quantos destinos: um (fila), vários (tópico, ou leque se cada um precisa reter). Depois, o que acontece se o destino estiver fora: se a resposta aceitável for "espera", é fila. Por fim, quem decide o destino: se for o conteúdo do evento ou um serviço da AWS que o emitiu, é EventBridge. E quando o enunciado citar ordem ou duplicidade, vá direto para FIFO.
Se quiser outro ângulo1 vídeo
Como cai na sabatina
“Picos de pedidos derrubam o serviço de processamento e pedidos se perdem. Como redesenhar para não perder nada?”
Erros comuns
- Achar que fila padrão do SQS garante ordem. Ela é de melhor esforço e pode entregar a mesma mensagem mais de uma vez; ordem estrita e exatamente uma entrega são da fila FIFO.
- Esquecer que o consumidor precisa apagar a mensagem. Sem a exclusão, ela reaparece quando o tempo de visibilidade expira — que é justamente o que protege contra consumidor que morreu no meio.
- Usar SNS quando o requisito é absorver pico. Tópico entrega e esquece; se o assinante estiver fora, a mensagem se perde. Absorver carga e reter é fila.
- Usar SQS quando o requisito é avisar vários sistemas. Uma mensagem na fila é consumida por um consumidor; para vários destinos, é tópico, ou tópico com uma fila por destino.
- Tratar EventBridge como fila. Ele roteia eventos por regra para destinos; não guarda para consumo posterior nem tem tempo de visibilidade.
- Não configurar fila de mensagens mortas. Sem ela, uma mensagem que sempre falha fica reprocessando para sempre e trava a fila.
Flashcards
Card 1 de 13
0 certos · 0 a reverDrill
Fila, tópico ou barramento?
Para cada necessidade, diga o serviço esperado.
1.Absorver um pico de requisições e processar depois, sem perder nada.
2.Notificar por e-mail e SMS quando um alarme disparar.
3.Disparar fluxos diferentes conforme o campo 'tipo' do evento.
4.O mesmo pedido precisa ir para faturamento, estoque e envio, cada um com retentativa própria.
5.Processar transações financeiras na ordem exata em que chegaram, sem duplicar.
6.Reagir quando uma instância EC2 muda de estado.
Quiz · 1 de 4
Uma aplicação de pedidos perde requisições durante picos, porque o serviço de processamento não acompanha o volume. A empresa exige que nenhum pedido seja perdido e quer o MENOR esforço operacional. Qual solução atende?
Explique para um gerente
Explique em um minuto por que colocar uma fila entre dois sistemas faz o conjunto aguentar mais, mesmo sem nenhum servidor a mais.
Se travar numa palavra técnica, é sinal de que ainda não entendeu essa parte.
Prefiro falar em voz alta
00:00
Toque para gravar, ou responda em voz alta sem gravar